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Making Sense of Fahrenheit 



Last December, the wraps 
came off a plan by Microsoft 
and SGI to integrate their 
graphics strategies into one 
unified vision, code-named 
"Fahrenheit." Unfortunately, many of us 
feel as if not all of the wrapping paper 
was removed from this early Christmas 
present: many of Fahrenheit's implica- 
tions remain unclear. 

Here is some of what's known thus 
far. Three new APIs will be developed by 
Microsoft and SGI, with input from 
Intel, Hewlett-Packard, and some other 
IHVs and ISVs along the way. These 
three APIs are: 

1. A Low-Level API for accessing low- 
level hardware. This will supercede the 
current Direct3D and OpenGL APIs, yet 
will retain elements of both (with a dash 
of DirectDraw thrown in). This API will 
definitely be COM-based on the 
Windows platform, and Microsoft has 
said it will be an evolutionary step for- 
ward for current Direct3D users, just as 
Direct3 D has evolved in various ways 
over the years. In fact, it might be help- 
ful just to think of it as a future version 
Direct3D, since I bet that's what it will 
be under Windows. Approximate arrival 
date: 2000. 

2. A Scene Graph API, consisting of a 
framework that sits on top of the low- 
level API and manages the geometry 
and data making up a scene. By adding 
a layer of abstraction away from the 
hardware, this API lets developers con- 
centrate on application content rather 
than coding to the underlying system. 
According to SGI, the Scene Graph API 
will incorporate technologies from the 
company's Performer, Open Inventor, 
and Cosmo tools, as well as recent 
OpenGL advancements. Approximate 
arrival date: 1999. 

3. The Large Model Visualization API. 
LMV is based on Hewlett-Packard's 
DirectModel and SGI's OpenGL 
Optimizer technologies. It's primarily 
for industrial-strength prototyping 
applications involving millions of poly- 
gons and very complex data sets — 
think automobile engineering analysis. 

Fahrenheit documentation states that 
"developers can feel confident that there 
will be a high degree of functional con- 



sistency between their current OpenGL 
applications and the Fahrenheit Low- 
Level API." Yet Microsoft recommends 
going forward with DirectDraw and 
Direct3D from here on out, as the 
migration path from future OpenGL 
iterations (that is, after version 1.2) to 
Fahrenheit under Windows won't be as 
easy. This has called into question the 
graphics strategies of game developers 
for the coming years. 

The result of this confusion? A lot of 
conjecture by game developers as to 
what the Fahrenheit announcement 
means and what their best course of 
action is. Some developers view it as SGI 
capitulating to Microsoft, and lament 
the passing of one of the last bastions of 
excellent technology not fully co-opted 
by the powers-that-be in Redmond. 
However, let's all take a deep breath and 
resist a knee-jerk reaction. Rather than 
fanning the flames on the Direct3D vs. 
OpenGL spat, let's put our energy into 
constructive dialog with these compa- 
nies as they try to create a solid founda- 
tion for a unified graphics standard. 

You can expect thorough coverage 
and analysis of Fahrenheit in Game 
Developer in the coming months. Mean- 
while, write us at gdmag@mn.com with 
your questions and reactions. We'll pub- 
lish your letters in an upcoming issue. 

Hook on Hiatus, Lander Joins Us 

This month, we're joined by a new 
Graphic Content columnist, Jeff Lander. 
Jeff is taking over for Brian Hook, who 
imparted much of his considerable 
knowledge about graphics program- 
ming to us in 1997. Unfortunately for 
us, Brian got involved in a little side 
project called id Software along the way, 
and his column-writing time began to 
dwindle. We'll miss him, but he's going 
to stick around as a member of our advi- 
sory board. Fortunately, Jeff Lander is 
also a phenomenal developer as well as 
an excellent writer, and we're fortunate 
to land him. Welcome, Jeff. ■ 
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Third-Party Libraries 




■ n response to Brian Hook's column 
I in the January 1998 issue of Game 
Developer ("Graphic Content/' p. 11), in 
which he discusses perceived problems 
with using prepackaged software 
libraries — his assertions reflect a com- 
mon attitude among some of the 
younger Internet crowd who claim to 
"know" all about software libraries that 
they've never tried. 

Brian's conclusions are based upon 
false assumptions — that external 
libraries are buggy, require 
workarounds that take 
longer to 
imple- 
ment 
than writ- 
ing the code from 
scratch, are not 
optimized, are 
inflexible, are poorly 
supported, and are inca- 
pable of adding functionality except at 
the whim of the original author. He 
presents these "facts" with no evi- 
dence, in the spirit of "everybody 
knows it to be true." 

I am the senior programmer at Ted 
Gruber Software, and I would like to 
address some of the myths surrounding 
software libraries. 

We have been developing the 
Fastgraph libraries for more than 10 
years. Our libraries are highly optimized 
in hand-written assembly language. 
They support most compilers and virtu- 
ally all video cards. They are copiously 
documented and are essentially bug- 
free. The rare customer complaints we 
receive are given priority treatment, and 
if a bug is actually found, it is usually 
fixed the same day. 

Brian asserts that if the library author 
isn't amenable to adding the particular 
feature that you want, then you are "in 
trouble." This is simply baffling. 
Fastgraph is modular, like a set of build- 
ing blocks. If you need a block that's 
not in Fastgraph's block set, you simply 
add another block. You don't need to 
throw away everything you've built. 

His claim that "The software compo- 
nent that you purchased might look 
great on paper, but when you drop it 
into your program and then spend a 
week looking for a bug that turns out to 
be a part of your new magic software IC, 



well, you tend to snap out of your dream 
world pretty quickly" is simply offensive. 
Not one of our customers has ever report- 
ed experiencing anything like that. This 
kind of polemic may sell to the masses, 
but it is inaccurate and damaging. 

Finally, let me tell you something 
about writing 



games. They^ 
need to 
be writ- 
ten 

quickly 
and 
shipped the 
same year. If 



Got something to say? [-mail us at 
gdmag@mfi.com. Or write tote 
Developer, 600 Harrison Street, San 
Francisco, CA 94107. 



you spend 10 months 
of that year re-inventing 
the wheel, your competition 
is going to beat you out the door, 
id Software manages to stay abreast 
of technology, but they've been 
doing this for many years. If you're 
a new company with new program- 
mers writing a new game, you need 
to hit the ground running. The tiny 
amount you spend on software 
libraries will shave months or years off 
of your development cycle. 

Don't believe everything you hear 
on the Internet. When you are making 
a decision about whether to invest in 
software libraries, base that decision on 
facts, not newsgroup rhetoric. 

Diana Gruber 
Senior Programmer 
Ted Gruber Software Inc. 



BRIAN HOOK REPLIES: I am baffled by 
the vehemence with which Diana Gruber 
objects to what are common sense asser- 
tions on my part. She misrepresents my com- 
ments appallingly. I did not state that I am 
familiar with software that I have never tried, 
nor did I claim that all external libraries 
exhibit all the negative attributes listed. My 
opinions are based on my experience work- 
ing with many libraries and APIs over eight 
years. I have encountered bugs and perfor- 
mance issues with many different third -party 
libraries, including the run-time libraries that 
come with many compilers and DOS exten- 
ders, public-domain "freeware" libraries, 
window system abstraction libraries, 2D and 
3D graphics libraries, and operating system 
APIs. Bugs are a part of life when you pro- 
gram for a living. Intel processors have bugs. 
BlOSes have bugs. Peripheral hardware has 
bugs. To believe that only a handful of third- 
party libraries and APIs possess bugs is 
naive, and the implication that my comments 



are the ramblings of an inexperienced kid is 
offensive. 

If she wishes to assert that Fastgraph is 
bug- free, extensible, well documented, well 
supported, and fast — it sounds like a great 
product! I have no quarrel with that library — 
I've never used it, nor have I claimed such. 

Even so, she states that Fastgraph sup- 
sports "most" compilers and "virtually all" 
L video cards. Which means that there is 
ia real chance that someone who uses 
J Fastgraph could run into problems 
'when attempting to find support for a 
r new or heretofore unimportant (for the 
end user) compiler or hardware device. 

Stories such as this are not uncommon: a 
company is using Compiler ABC and thus gets 
library XYZ. However, 14 months into the pro- 
ject, the company switches to Compiler J KL 
because of unrelated technical issues, only to 
find that XYZ does not support JKL. I've been 
in this situation — it occurs often. It hap- 
pened at id when we wanted to release the 
Doom source code. We found that there was a 
dependency in the DOS version on a third- 
party library, which meant that the Linux code 
had to be released instead. While Fastgraph 
may be modular and extensible, most of the 
libraries that I have worked with are mono- 
lithic and most decidedly not extensible. 

I agree wholeheartedly that games need to 
be written quickly — although shipped the 
same year is pushing it quite a bit. I haven't 
seen a professional game implemented and 
shipped in less than 12 months in quite some 
time. I haven't dismissed the notion of third- 
party libraries out of hand — I simply urge 
caution when considering committing to such 
packages. For example, id Software is a big 
proponent of Op enGL — a third-party library 
— and we use it extensively. As a result, 
we've endured poor hardware and worse dri- 
vers. Still, we feel that OpenGL's advantages 
outweighed its disadvantages. So it's not as 
if we're some kind of API Luddites who wor- 
ship at the altar of NIH — we simply take into 
account the trade-offs that exist when select- 
ing each of our development tools. 

Finally, I don't understand her obsession 
with newsgroups or the Internet, but if 
you're thinking about buying into someone 
else's technology, you would be irresponsi- 
ble not to solicit the opinions of others who 
have used that technology — whether 
those opinions come in the form of e-mail, 
print reviews, Websites, Usenet posts, or 
Pony Express is irrelevant. Such commit- 
ments should be made with as much data 
as possible. I'm curious where "facts" 
should be drawn from — press releases and 
marketing collateral? 
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I N D U ST RY AliaslWavef rant's Maya 
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btf Alex Duhnc 

HERE COMES THE GOD SQUAD. Mike Wilson 
has signed on a strong roster of game devel- 
opers to the Gathering of Developers. 
Developers include Apogee/3D Realms, 
Epic Megagames, PopTop Software, Ritual 
Entertainment, and Terminal Reality. The 
squabble between GT Interactive and 
Apogee/3DR over who will publish the 
forthcoming Max Payne title may not be the 
only speed bump that GOD encounters as it 
continues to lure developers with sky-high 
(about 40-50%) returns on sales, but that 
should be expected during a transition peri- 
od like this. The high rate of return GOD 
promises its developers could cause some 
bidding wars by publishers over upcoming 
titles. Big winner? Developers. Incidentally, 
Wilson says that GOD will ship four games 
this year, and he's shooting to get seven out 
the door in '99. 

THE LONELY GUY? The Sega layoffs 
announced on January 9 may have only 
trimmed 30% of the company'sworkforce as 
announced, but the 
layoff decimated 
the Sega of 
America division. 
Just one channel 
salesperson 
remains in that divi- 
sion. With Saturn sales in the can, and its 
next-generation system (Dural) a long way 
off, the company was left with few options 
for its sales force. I doubt that last guy is 
working on straight commission. 
RIDING THE WAVES. AMD is weathering 
some pretty severe ups and downs right 
now. Up: it shipped close to 1.5 million K6 
processors during the fourth quarter (thanks 
to its major deal with Compaq), nearly 
achieving the company's goal. Down: It has 
problems with declining liquidity and ana- 
lysts are contemplating downgrading its 
stock. Up: AMD-3D technology is gaining 
buy-in from game developers like 
Dreamworks and Digital Anvil, and tool 




ALIAS I WAVE FRO NT is finally releasing Maya, its innovative computer graphics 
and animation application. It purports to be the next generation in 3D character 
animation and visual effects technology. 

Alias|Wavefront developed many 
architectural innovations to maxi- 
mize system performance. Maya com- 
bines object-oriented C++ design with 
a native OpenGL graphics implemen- 
tation to provide high levels of 
throughput for computational and 
interactive tasks.Three architectural 
components give Maya power as an 
animation system. The first is the 
Dependency Graph, Maya's node- 
based architecture. The second is 
MEL, Maya's unique scripting lan- 
guage, which gives users flexibility in 
extending Maya. In addition, Maya's 
C++ API allows users to add custom 
plug-ins to tailor the program to spe- 
cific production requirements. The application also incorporates a comprehensive 
set of features spanning modeling, animation, and rendering. Maya definitely 
focuses on ease-of-use; it allows artists to use a wide variety of character building 
tools and techniques to create digital puppets with embedded behaviors and high 
level controls. Once built, these digital puppets may be posed and animated by 
other artists without requiring them to understand all of the underlying technol- 
ogy- 
Hardware requirements for Maya are: R4000 or higher processor, 24-bit graph- 
ics, OpenGL native preferred, and at least 128MB RAM. It runs on IRIX 6.2 or 
higher. Base price for Maya starts at $10,000; additional modules range from 
$5,000 for Artisan, to 10,000 for each other module. 
■ AliaslWavefront 
Toronto, Canada 
(416) 362-9181 

www.aw.sgi.com/pages/ maya_transition_web/ 



Image created by C. Landreth using 
AliaslWavefront's Maya. 



PowerMoves I 



CREDO INTERACTIVE Credo 
Interactive unveiled Life Forms 
PowerMoves I, a 3D animation library 
that complements the company's Life 
Forms character animation software. 

Life Forms is a stand-alone tool for 
creating, editing, and playing back 
character animation. It features a built- 
in walk generator, motion capture data 



support, graphical editing tools and its 
own animation libraries. PowerMoves I 
adds over 600 keyframed single and 
multi-figure 3D animation sequences 
to Life Forms, including office moves, 
sports activities, dancing, walking, and 
running. The PowerMoves collection of 
basic sequences serves as a starting 
point for animation projects, as these 
keyframed animation segments can be 
modified to get the specific look and 
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feel an animator requires. 

Life Forms and PowerMoves work 
with Infini-D, Extreme 3D ; 
Electriclmage, 3D Studio R4, Pixel 
Putty, and any program that supports 
BioVision or Acclaim motion capture 
file formats, or VRML 1 and 2 formats. 
Support for LightWave 3D and 3D 
Studio MAX is currently in develop- 
ment. Power Moves I sells for $249. 
■ Credo Interactive 

Burnaby, British Columbia, Canada 

(604) 291-6717 

www.credo-interactive.com 

DeBabelizer 3 for Mac OS 

EQUILIBRIUM just released the latest 
Macintosh version of DeBabelizer 3. 

Already a standard graphics proces- 
sor in desktop publishing, multimedia, 
and the Web, this new upgrade of 
DeBabelizer took "Best of Show" at 
January's Macworld Expo in San 
Francisco. DeBabelizer automatically 
and efficiently optimizes, translates, 
and processes graphics so that you can 
deliver content with the highest level 
of image quality across a variety of 
platforms. DeBabelizer 3 features a 
new, more intuitive interface that 
streamlines batch automation func- 
tions, allows an unlimited number of 
open image files, and grants more 
extensive drag-and-drop capabilities. 
The product also provides improved 




The new user interface for DeBabelizer 3. 



Web support. There are more powerful 
color reduction capabilities, including 
new built-in niters, enhanced plug-in 
filter support, and the ability to create 
SuperPalettes from any base palette. 
DeBabelizer 3 also features full CMYK 
support, more powerful scripting capa- 
bilities, and additional file formats. 

DeBabelizer 3 runs on the Macintosh 
OS, and has a suggested retail price of 
$595. 

■ Equilibrium 

Sausalito, California 
(415) 332-4343 
www.equilibrium.com 

CodeWarrior in AND-3D 

METROWERKS and AMD have 
entered into a relationship, whereby 
CodeWarrior Professional will now 
support the AMD-3D technology. 

CodeWarrior Professional offers 
developers a complete set of tools for 
writing programs optimized for the 
AMD-K6 processor and AMD-3D tech- 
nology. CodeWarrior gives you inline 
assembly support for AMD's 3D instruc- 
tion set. It will also allow you to opti- 
mize your code for the AMD-K6 proces- 
sor. You can optimize for AMD-3D 
technology on a per-function basis, let- 
ting you exploit the speed of the new 
3D instruction set. Finally, CodeWarrior 
utilizes vectorization compiler tech- 
niques to take advantage of the parallel 
instruction capabilities of the 
AMD-3D technology. 

CodeWarrior Professional for 
AMD-3D technology supports 
C, C++, Java, and Pascal. It 
requires a 486 processor or 
higher, at least 16MB of RAM, 
Windows 95/NT 4.0, CD-ROM 
for installation, and 80MB of 
hard disk space. It sells for 
■ $449. 

I ■ Metrowerks 
Austin, Texas 
(512) 873-4700 
www.metrowerks.com 



makers like Metrowerks. Down: Company 
executives have stated that Q1 may not be 
rosy financially, since it's switching over to 
.25 micron technology from its current .35 
micron manufacturing process. This should 
be a telling year for the company. 
NEW TITLES ON TOP. Those tag-team cham- 
pions of the PC Data charts. Riven and Myst, 
were finally dethroned for the week after 
Christmas (Dec. 28 - Jan. 3) by Quake 2 and 
Microsoft Flight Simulator. The first or sec- 
ond spot on the monthly top seller list has 
been occupied by either Riven or Myst 
going all the way back to last June — quite 
an impressive streak. 

CUC NOW CENDANT. As a result of a merger 
between CUC International and HFS Inc., 
CUC Software is now Cendant Software. 
The merger widens the scope of this 
already diverse company. Formerly, 
Blizzard, Sierra On-Line, Davidson & 
Associates, and Knowledge Adventure 
shared the same corporate roof with Days 
Inn, Howard Johnson, Ramada, and Avis. 
Now Century 21, Coldwell Banker, and ERA 
become corporate sisters too. No word as to 
whether low fixed-rate mortgages are now 
part of employee incentive packages at 
Cendant's game studios. . . 
CHRIS' CAST NAMED. Cast members for 
Chris Roberts' upcoming Wing Commander 
flick have been named 
— not that you'll rec- 
ognize them by name, 
necessarily. The 
stars include Freddie 
Prinze Jr. (I Know 
What You Did Last 
Summer), Saffron Burrows (Circle of 
Friends), Matthew Lillard (Scream), and 
Elise Neal (Scream 2). The film is now in 
production in Luxembourg and Germany. 
IT WAS A GOOD YEAR. Bloomberg News 
has identified the game development indus- 
try as a "bright spot for investors in 1998." 
The respected financial news organization 
expects PC game sales to climb 30% this 
year to over $400 million. In addition, the 
market research firm, NPD Group, predicts 
that when all is said and done, 1997 will 
have seen an increase in the video-game 
business of up to 45 percent over '96. 
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Better 3D: 

The Writing Is on the Wall 

Have you ever come up with the solution to a problem at an unfortunate 
time? It can strike so suddenly. You know that if you don't write it 
down immediately, the solution may be lost forever. There are times 
when I wake from a sound sleep with the answer to a problem that's 




been bugging me for days. 
Occasionally, I have to jump up and 
crank on the computer to try it out 
right away. Most times though, I just 
roll over and go back to sleep. 
Epiphany or not, a guy needs his rest. 

This phenomenon didn't begin with 
the computer age. In fact, long ago, the 
mathematician Sir William Hamilton 
found himself in the exact same situa- 
tion. In the early 1830s, he was trying 
to extend complex number theory 
from 2D to 3D. Hamilton believed that 
a complex volume could be denned by 
one real and two imaginary axes. He 
worked on this problem for over a 
decade with no luck, and I might add, 
without the aid of a computer. Then, 
on October 16, 1843, while walking 
past the Broome Bridge to a meeting at 
the Royal Irish Academy in Dublin, the 
answer came to him. Hamilton realized 
that he needed three imaginary units 
with some special properties to 
describe the volume. He was so excited 
and so fearful of losing the answer for 
all time, that he carved the formula 
into the side of the bridge with a knife. 
It's a good thing he didn't roll over and 
go to sleep. 

He called his solution a "quater- 
nion," and it looks like this: 

q = a + bi + cj + dk 



Although I've never come up with 
something so good that I needed to 
carve it into the side of a bridge, I do 
have some ideas for animating charac- 
ters that I've wanted to implement for 
years. Until now, I've had problems 
making these ideas come to life. Some 
of my problems are solved by better 
hardware and some are solved by just 
plain hard work. Today's problem has 
been solved by a combination of both. 
But what, you ask, do quaternions and 
my problems with animating charac- 
ters have to do with game program- 
ming? Read on. 

Now that we have the ability to cre- 
ate complex real-time characters, the 
challenge lies in bringing these charac- 
ters to life. So how do I do that success- 
fully? It really comes down to a prob- 
lem of data storage and playback. What 



I need to store is the position and ori- 
entation of each "bone" in the charac- 
ter that I'm animating. 

Last month, Nick Bobick wrote about 
using quaternions for camera anima- 
tion and physical simulation ("Rotat- 
ing Objects Using Quaternions," Feb- 
ruary 1998). We are going to apply the 
same concepts to character animation 
in OpenGL. 



Character Animation 

Animation data is normally stored in 
keyframes. These keyframes are 
recorded periodically. For instance, 
motion capture data is often recorded at 
30 frames per second (fps), the standard 
NTSC video playback rate. Obviously, 
such a high frame rate generates a lot of 
data. In order to save precious RAM, 
many game applications store animation 
data at a much lower rate, say 10 fps. 

However, modern 3D action games 
try to run quite a bit faster than 10 fps. 
A game running at 30 fps will show 
three times as many frames as a 10 fps 



Who is this Jeff Lander dude, anyway? Jeff's a maniacal research nerd who loves the 
challenge of computer graphics programming when not mountain hiking by the 
beach. He is always willing to learn more, and in fact, thrives on it. If you have any- 
thing you want to learn more about or something you would like to discuss, contact 
Jeff a t jeffl@darwin3d. com . 
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animation. This leaves you with a couple of options. The first 
option is to repeat or hold the same keyframe over three game 
cycles until the next animation frame arrives. This approach, 
however, can make your animation look a bit jerky. 

The second option — and I consider this to be the better 
solution — is to create frames in real time that are in- 
between the existing keyframes. You generate these in- 
betweens by interpolating where the bone is at a given 
time between your keyframed data. Coming up with a 
method by which to calculate this in-between position is 
where I start hitting the wall (or bridge). 



Euler Angles 

The most common method of representing the current 
orientation of an object is through the use of Euler 
angles. This method represents the absolute orientation of 
an object as a series of three rotations about three mutually 
orthogonal axes, normally labeled x, y, and z. These Euler 
angles describe the three angular degrees of freedom. It's 
important to remember that by applying these rotations in 
different orders, you'll get different final orientations. So 
it's best to stay consistent. 

If you saw the movie Apollo 13, you were probably amused 
by those guys whipping out their slide rules and complain- 
ing about something called "gimbal lock." Well, as strange 
as it sounds, gimbal lock can be a real problem. It's named 
after a situation that occurs in a mechanical gyroscope con- 
sisting of three concentric rings. Under certain rotations, the 
support for the gyroscope, called a gimbal, could lose of a 
degree of freedom. 

This problem has a parallel in computer graphics. Bobick 
explained the situation in his February article, but it may help 
us to visualize it. Because Euler angles do not act indepen- 
dently of each other, it's possible to lose a degree of freedom. 
Therefore, a change to one of the angles affects the entire sys- 
tem. Let's look at an example. If I take the object in Figure la 
and rotate it 30 degrees about the x axis, I'll get the image in 
Figure lb. I now rotate the object 90 degrees about the y axis, 
resulting in Figure lc. As you can see, the current z axis is in 
line with the x o axis. What we have now is gimbal lock. Any 
further rotation about the z axis affects the same degree of 
freedom as rotating about the x axis. I have completely lost 
the ability to rotate around the third degree of freedom. In 
many 3D modeling packages, it's possible to avoid this prob- 
lem by creating a parent to this object and rotating the parent 
to gain back the additional degree of freedom. However, in a 
real-time 3D game, this isn't really possible. 

The second problem with the use of Euler angles involves 
generating an in-between. In order to animate my character 
smoothly, I need to interpolate a new position out of the 
existing keyframes in my animation data. The fact that the 
Euler angles don't act independently of each other again 
raises a problem. I could represent the orientation of an 
object as (0,180,0) degrees about (x,y,z) respectively. This 
same orientation could also be described as (180,0,180). 
Now, what if I want to generate a position halfway between 
(0,0,0) and both orientations? In the first case, I would get 
(0,90,0) (Figure 2a), but in the second case I would get 
(90,0,90) (Figure 2b). Clearly, these two orientations are not 
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equivalent. These two problems with 
animating Euler angles lead me to look 
for a better way to store orientations for 
my animation. 

Quaternions 

i y using quaternions to represent the 
* orientation of an object, I can avoid 
the drawbacks of using Euler angles. A 
quaternion, when used to represent the 
orientation of a rigid body in space, is 
defined by two parts: a vector that 
describes the axis of rotation and a scalar 
value. When two quaternions of unit 
magnitude are multiplied together, they 
generate a single quaternion of unit mag- 
nitude — this is crucial to the use of 
quaternions for representing rotations. 
So, to use this system of animation, I 
have to convert my orientations from 
Euler angles to quaternions. For details on 
how quaternions are multiplied together I 
would suggest the Shoemake article that 
is referenced at the end of this column. 



Conversion from Euler Angles to 
Quaternions 

otations are defined as the follow- 
ing quaternions using [(x,y,z),w] 
notation, where (x,y,z) is a vector and w 
is a scalar value. 

Euler (x = y = 9, z = <|>) 
Q x = [(sin(i|//2),0,0), cos(\|//2)] 
Q y =[(0,sin(6/2),0), cos(9/2)] 
Q z =[(0,0, sin^/2)), cos^/2)] 



LISTING 1 . Conversion from Euler angles to quaternions. 



Illllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll 
II Function: EulerToQuaternion 

// Purpose: Convert a set of Euler angles to a quaternion 

// Arguments: A rotation set of 3 angles, a quaternion to set 

// Discussion: This creates a Series of quaternions and multiplies them together 
// in the X Y Z order. 

Illllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll 
void EulerToQuaternion (tVector *rot, tQuaternion *quat) 
{ 

/// Local Variables lllllllllllllllllllllllllllllllllllllllllllllllllllllllllll 

float rx,ry,rz,ti,tj,tk; 

tQuaternion qx,qy,qz,qf; 
lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll 

II FIRST STEP, CONVERT ANGLES TO RADIANS 

rx = (rot->x * M_PI) / (360 / 2); 

ry = (rot->y * M_PI) / (360 / 2); 

rz = (rot->z * M.PI) / (360 / 2); 

// GET THE HALF ANGLES 

ti = rx * 0.5; 

tj = ry * 0.5; 

tk = rz * 0.5; 



qx.x = sin(ti); qx.y = 0.0; qx.z = 0.0; qx.w = cos(ti); 
x = 0.0; qy.y = sin(tj); qy.z = 0.0; qy.w = cos(tj); 

cos(tk); 



qy 



qz.x = 0.0; qz.y = 0.0; qz.z = sin(tk); qz.w 

MultQuaternions(&qx ,ftqy ,ftqf ) ; 
MultQuaternionsUqf ,&qz,&qf ) ; 



quat->x = qf .x; 
quat->y = qf .y; 
quat->z = qf .z; 
quat->w = qf .w; 

} 

//EulerToQuaternion ///////////////////////////////////////////////////////// 
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This gives us the 
axis and angle that 
we need. To use it 
in OpenGL, the 
last thing to do is 
convert angle § 
from radians to 
degrees, because 
OpenGL is expect- 
ing degrees (Listing 
2). Since the data is 
now in the correct 
format for 
OpenGL, the actu- 
al display code is 
very straightfor- 
ward (Listing 3). 



By multiplying these quaternions 
together, I get a single quaternion rep- 
resenting the orientation of the object. 
The code for this conversion is shown 
in Listing 1. 

This routine is set up to handle rota- 
tions in the order xyz. If your rotations 
are stored in a different order, you may 
need to be make some adjustments. By 
combining functions, it is possible to 
speed this up a bit. In the code that 
accompanies this article, I reworked it 
as a secondary conversion routine. 

OpenGL Implementation 

Since my eventual output is 
through OpenGL, I need to con- 
vert the quaternion back into some- 
thing useful. The glRotatef command 
takes an axis to rotate around and the 
angle of rotation about that axis. This 
axis-angle representation was explored 
briefly in Chris Hecker's column 
"Physics, Part 4: The Third Dimension" 
(Game Developer, June 1997, pp. 17-18). 
This representation is very similar to 
the quaternion form. The quaternion is 
defined as a rotation of § about the axis 
(x, y, z) such that 

q = cos((|)/2) + x sin((|)/2)i + y sin((|)/2)j + 
z sin((|)/2)k 

Therefore, the axis and angle of rota- 
tion can be retrieved from a quaternion 
by simple algebra. 

4> = acos(Q w )*2 
x = Q x /sin((t>/2) 
y = Q y /sin((^/2) 
z = Q z /sin(((>/2) 



Where Does That Bring Us? 

The question is, "If quaternions are 
so great, why not use them all the 
time?" You certainly could. However, 
most people find it difficult to visualize 
the orientation of an object as a quater- 
nion. People (at least 3D programming 



dweebs) are often more comfortable 
visualizing an orientation as Euler 
angles. This is an important considera- 
tion when you're creating a tool that 
will be used by artists and program- 
mers. I'm sure people confronted with 
a dialog box asking them to enter the 
quaternion for a rocket ship would 
have some problems. At least Euler 
angles are a little more friendly. 

The sample application uses the pre- 
viously mentioned conversion routines 
to display an object using either Euler 
angles or quaternions. By switching 
between these display methods, you 
can see that both representations result 
in the same final display (Figure 3). 

Using these routines, I now have a 
method for converting my Euler angle 
rotations into quaternions and then 
displaying them. Whew! This has been 
a lot of difficult stuff. But now we have 
the foundation. From here, I need to 
start animating these orientations. 
Next time, I'll add the interpolation 
code and build an application to dis- 
play the in-betweens. ■ 



LISTING 2 . Converting the angle to degrees. 



/////////////////////////////////////////////////////////////////////////////// 
II Function: QuatTo Axis Angle 

// Purpose: Convert a quaternion to Axis Angle representation 

// Arguments: A quaternion to convert, a axisAngle to set 

/////////////////////////////////////////////////////////////////////////////// 

void QuatTo Axis Angle (tQuaternion *quat,tQuaternion *axisAngle) 

{ 

/// Local Variables lllllllllllllllllllllllllllllllllllllllllllllllllllllllllll 
float scale, tw; 

/////////////////////////////////////////////////////////////////////////////// 
tu = (float) acos(quat->w) * 2; 
scale = (float)sin(tw / 2.0); 
axisAngLe->x = quat->x / scale; 
axisAngLe->y = quat->y / scale; 
axisAngLe->z = quat->z / scale; 

// NOW CONVERT THE ANGLE OF ROTATION BACK TO DEGREES 
axisAngLe->u = (tw * (360 / 2)) / (float)M.PI; 

} 

// QuatToAxisAngLe 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 



LISTING 3 . Using quaternions in OpenGL 



II TAKE THE BONE EULER ANGLES AND CONVERT THEM TO A QUATERNION 

EulerToQuater nion (&cu rBone->rot , &cu rBone->quat) ; 

// QUATERNION HAS TO BE CONVERTED TO AN AXIS/ANGLE REPRESENTATION 

QuatToAxisAngLe(ftcurBone->quat,&axisAngLe); 

// DO THE ROTATION 

glRotatef (axisAngle. m, axisAngle. x, axisAngle. y, axisAngle. z); 
drawModel(curBone) ; 



GAME DEVELOPER MARCH 1998 



http://www.gdmag.com 



Hardware for OpenGL Developer Tools 



When developing an 
advanced real-time 
3D game engine and 
production tools, it's 
important to work on decent hardware. 
Likewise, when artists and designers work 
on those tools, performance means pro- 
ductivity. Now obviously, the 3D artists, 
modelers, and animators should have 
great systems. Any of the fully OpenGL- 
certified high-end graphics cards would 
also work well for production tools. 

But what about the programmers, level 
designers, balance testers, and so on? I 
would like a great production environment 
for everyone. Luckily for me, certain "mar- 
ket pressures" have pushed some con- 
sumer graphics hardware towards OpenGL 
support. For me, OpenGL support means 
that the images that I see in my modeling 
and animation program and in my toolset 
are identical. The material and display 
parameters match exactly. This is very 
important at the design level no matter 
which final game application API is used 



(OpenGL, Direct3D, or proprietary). Low- 
cost OpenGL acceleration allows compa- 
nies to get high-performance game pro- 
duction stations for all the team members. 

To be a good system for game produc- 
tion, a graphics card should support 
acceleration in multiple windows, 
because most 3D development tools 
require more then one viewpoint. It 
should support most, if not all, display 
features of the target platform. It should 
also have decent performance in the tool, 
as well as being able to run the actual 
game application at a decent rate. 

The 3Dlabs Permedia 2 chipset is an 
excellent choice for a low-cost OpenGL tool 
platform. 3Dlabs has much experience 
working with OpenGL through its Glint fam- 
ily of cards, and it shows. Its OpenGL dri- 
vers are stable and robust. The Permedia 2 
adds acceleration of glLines, which really 
can help a development tool. The lack of 
some blending modes may be an issue 
when previewing the application. However, 
the price/performance ratio is great. 



The new Nvidia Riva 128 chipset is a 
great performer. It has excellent potential 
as an all around perfect production card, 
as well as great speed and image quality 
and fast Windows acceleration. Right 
now, the OpenGL drivers are in testing, 
but I have high hopes for this card. 

The 3Dfx Voodoo Rush chipset is very 
interesting. It's certainly the king of the 
hill (right now) as far as actual game per- 
formance. However, the OpenGL support 
beyond full-screen game applications is 
questionable. The alpha driver that was 
released was unusable in a development 
environment, and I have yet to see 
whether the new beta OpenGL driver will 
accelerate graphics in a window. That 
said, a Voodoo card to run the game 
application combined with either of the 
other boards for the production tools is a 
great environment. 

The recent announcement that 
Microsoft is working with SGI to speed up 
and improve OpenGL driver development 
could change things dramatically. I will be 
watching closely. 

—Jeff Lander 



I've only scratched the surface of the math behind quater- 
nions. But as you can see, a whole lot of history rests behind 
them. People interested in reading more about quaternions and 
their use in computer graphics should read these sources. 

Hamilton, Sir William Rowan. "On quaternions; or On a New System of 
Imaginaries in algebra." Philosophical Magazine, XXV:10-13, 1844. 

This is the original paper describing the actual discovery. 
However, it's very mathematical and probably not necessary 
unless you have the desire to learn the underlying theory. 

Shoemake, Ken. "Animating Rotation with Quaternion Curves." 
Computer Graphics (Proceedings ofSiggraph 1985] 7:245-254, 

Shoemake, Ken. "Euler Angle Conversion." Graphic Gems II. Academic 

Press: 222-229, 1994. These papers were essential to my under- 
standing of the conversion process. The paper in Graphic Gems 
II actually handles the general case of different rotation orders. 

Watt, Alan and Nark Watt. Advanced Animation and Rendering 
Techniques. New York: ACN Press, 1992. This is a very good book 

that helped me with the background and comparisons 
between Euler angles and quaternions. 

Laura Downs has written a proof that quaternions really do rep- 
resent rotations. It's available at http://http.cs.Berkeley.edu/ 
~laura/csi84/quat/quatproof.html. Thanks to Ian Wakelin of 
Rhythm and Hues Studios for turning me on to that site. 

Also be sure to read Nick Bobick's article "Rotating Objects 
Using Quaternions," in the Feb. 1998 issue of Game Developer 
for other uses and a matrix-based approach. 
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ARTIST'S VIEW 



Communication 
Triangles 




rom love triangles to children manipulating their divorced parents — if 
you get three people together, you usually get problems. My theory is that 
this triangle issue is behind a common problem that artists face: dealing 
with small team conflicts. Let's explore this by starting with an example. 



Our Beloved Team: Albert, 
Dave, and Pam 

Albert Artist is a con- 
tract artist for Dave 
Developer, an experienced, 
one-man game develop- 
ment "company." Dave's 
got a signed deal with Pam 
Producer, who works for an 
up-and-coming game pub- 
lishing company and was 
just promoted from assis- 
tant to manager of her own 
project. Dave's worked with 
Albert before, but they 
didn't work closely togeth- 
er. Pam doesn't know either 
one very well, but has spent 
more time with Dave, negotiating the 
contract and approving the game 
design (which they've agreed is some- 
what vague, but good enough, given 
the aggressive development schedule). 
Let's start with Pam, sipping her morn- 
ing mocha and reading the day's first 
wave of e-mail: 

from: Dave Developer (dave@gameguy.com) 
to: Pam Publisher (ppubllsherCbigdogs.com) 
subject: Art Quality Control 
As far as accepting artwork, I think this 
should be my job, since I'm the one ultimate- 
ly responsible for the product. I'm open to 
other ideas, though. 
-Dave 




Pam sighs and leans back, wishing 
she could find the perfect outside 
developer for this project — some 
super-group with clean, efficient code 
and excellent artistic abilities and 
tastes, all the while affordable, avail- 
able, and easy to work with. But this 
project is just a basic sequel, not excit- 
ing enough to attract the top-notch 
developers. In fact, her boss isn't jazzed 
about it either — that's why the bud- 
get's not huge and the marketing effort 
is strictly average, which is also why 
she's working with a small, unknown 
company such as Dave's. 

Still, she's going to make the game as 
stupendous as possible. If she can get a 
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really solid game (fun game- 
play, good art, bug-free 
code, on time, and within 
budget) out of Dave and his 
V contractors, she'll get good 
I marketing and good distrib- 
I ution. With a little luck, it'll 
I do pretty darn well in retail. 
I That will be quite an 
achievement for her. 

And Dave can do it — she 
knows he's good. The code's 
going to be great, but she is 
a little worried about the 
artwork: is it going to be 
any good? 

Her coffee forgotten, Pam 
rereads the e-mail and pon- 
ders Dave's assertion. It 
makes sense, and she trusts 
Dave to do the right thing for the pro- 
ject, in general. The thing is, she's afraid 
that Dave can't tell first-rate characters 
from clip-art, so she's got to somehow 
ensure that the art is great. "I've got to 
do what's right for the project here," she 
reminds herself. This essential truth 
fuels her tickle of concern about the art- 
work as she composes her reply. 

from: Pam Publisher (ppublisher@bigdogs.com) 
to: Dave Developer (daveQgameguy.com) 
subject: Art Quality Control 
»I think this should be my job since I'm the 
»one responsible for the product ultimately. 
»I'm open to other ideas, though. 
I need some additional assurances that the 
artwork quality is going to be adequate. I'd 
like to see samples from the artist and get 
some proof that this art is going to be AAA- 
grade. You're in charge of the project — I 
just want to confirm the art quality. 
-Pam 
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Hunched in his darkened workspace, 
Dave's thumb-drum solo takes on a 
louder, almost militant beat as he 
rereads Pam's reply. "Is Pam micro- 
managing here?" he asks himself. "I 
guess I can understand why she'd want 
to see proof of artwork." Still, a nag- 
ging feeling of doubt eludes his mental 
fishing. On one 
hand, her request 
makes sense — 
she's just trying 
to make sure 
it's a top- 
notch 
product. 
But it def- 
initely bugs 
him that she's sec- 
ond-guessing his 
choices. He 
knows that if he's 
not in control of 
his own project, it'll be Disasterville. 

But Pam isn't like that. So far, she's 
been really good about not micro- 
managing. Besides, it's not like he has a 
choice — she's the publisher, she's got 
the cash — and all she wants is sample 
artwork. Semi-reassured, he writes to 
Albert. 

from: Dave Developer (daveDgameguy.com) 
to: Albert Artist (artdude€cheapisp.com) 
subject: Art Quality 
Hey Albert, 

So I need some samples to show to the pub- 
lisher. They're curious what you do, how it 
looks, and such. Forward me a couple .JPG 
attachments, O.K.? They want to see nifty 
stuff, such as those SIGGRAPH demos or some- 
thing all flashy. Whatever you've got handy. 
-Dave 

Albert heaves a long-suffering sigh. 
Why? He's already shown Dave his 
demo reel, and Dave said, "Rockin' 
art!" and didn't bring up art skills 
again. So what's going on now? 

He herds the cat off of his lap and 
leans back, rubbing his eyes. 
Something important is happening 
here, his intuition tells him. There's 
been a subtle shift, and now he's not 
sure who's calling the shots. What if 
the publisher doesn't like his work? 
Will he have a second chance? What if 
Dave likes something and this mysteri- 
ous publisher doesn't? What then? 

Albert's chair squeaks as he slowly 
spins 360 degrees. He knows that he 



and Dave can do good work together — 
Dave will give Albert the space he 
needs to make quality artwork, and 
Dave will help Albert make it fit into 
the technical limitations of the game. 
But with a third party involved, he's 
not so sure. Nightmares flit through his 
head: end of the project, Pam casually 
says, "Um, how about a more, y'know, 
cartoony feel?" He might be stuck beg- 
ging for approval from the headless 
monster of their publisher's art direc- 
tion, as Dave stands helplessly at his 
side. How can anyone make decent art 
under these conditions? 



Options 



In my opinion, this project is in 
trouble. "Hey, whoa!" you say, 
"What's the big deal? It's just a simple 
project, and all these people possess 
good intentions and reasonable judg- 
ment. Heck, nothing's even happened 
yet — they're only talking about a 
problem!" 

First, the timing issue: On most bad 
projects, once we see actual problems 
(someone quitting, major design 
changes, and so on), it's too late to do 
much about it. The time for quick 
action is when the project is teetering 
on the brink — when everyone's talking 
about it, but nothing's happened yet. 

Second, the most important risk to 
the project is loss of goodwill, not qual- 
ity of artwork. If Pam isn't careful, she 
could easily give Dave and Albert the 
impression that she's an ignorant boss 
who wants to play developer and get 
her "touch" on the product. If Dave or 
Albert overestimate or get defensive 
about their skills, Pam will probably 
have to confront them with a truthful 
assessment of their roles in the grand 
scheme, and that might cause a very 
severe loss of trust. 

So let's assume that our intrepid 
team is reasonable. Yeah, they're all 
good, fair, hardworking, and honest. 
They've promised to floss twice a day 
and to make every effort not to get 
pointlessly emotional about this. Even 
so, I still say that the project's goodwill 
is at serious risk. Let's appreciate the 
gravity of the problem by looking at 
some possible solutions, starting from 
Albert's point of view. 

One option for Albert is to insist on 
taking art direction from Dave. That's 



how things currently are — legally 
Dave and Albert have a contract and 
Albert has no connection to Pam. 
Theoretically, if Albert keeps up his 
end of the deal with Dave, he has 
nothing to worry about. 
Unfortunately, that's not realistic, 
because Pam holds Dave's purse 
strings. If she's forced to work through 
Dave for artistic concerns, this will 
quickly prove frustrating for everyone: 
Pam would rather talk directly to 
Albert, and because Dave isn't an art 
director, he's not going to be good at, 
or enjoy, taking Pam's criticism and 
turning it into improved artwork. Poor 
Albert will labor to decipher Pam's 
intent through Dave's warped filter. 
This is a likely recipe for poor art quali- 
ty, as well as frustration all around. 

Another option is for Albert to work 
side-by-side with Dave, and for both of 
them to report to Pam. Pam gets direct 
access, and Albert takes responsibility 
for (and has more control over) the 
artwork quality. This is a big change. 
Albert will probably be paid by Pam. 
But Dave's control is weakened 
because Albert is now a peer, not a 
subcontractor. And Pam's job gets 
harder. No one person (besides Pam) is 
responsible for the project: if Albert's 
artwork is late, that's not Dave's prob- 
lem anymore. So, Pam becomes 
involved in project management and 
takes over more of Dave's duties. This 
may create resentment between her 
and Dave. What if Albert isn't quali- 
fied for the job? Designing artwork is 
actually quite different from building 
art from a design. In fact, Albert him- 
self may not want the job. Most pro- 
duction artists leap at art design/lead 
job opportunities, but happy produc- 
tion artists may turn down stressful sit- 
uations such as this. 

A third option is for Albert to try to 
compromise. Satisfy 
Pam by dis- 
cussing art 
quality directly 
with her, 
while still 
working 
under Dave. 
Compared to 
the previous 
two options, 
this one sounds 
more reasonable, 
and it has the appeal 
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of "good faith." But it's high risk; it 
could combine the worst parts of the 
two previous options. Also, Albert loses 
because he would have the responsibil- 
ity of art quality without the recogni- 
tion, power, or pay of the actual job. 
For instance, it's likely that Pam will 
ask Albert to make art changes. Since 
she's not an art director, they may not 
be good ideas, and Albert isn't in a 
position to object. Another problem is 
simply that Albert now has two bosses. 
What will he do if Pam and Dave give 
conflicting assignments? 

So, neither Dave nor Pam is really 
qualified to direct artwork, and Albert 
wasn't really hired to design the 
game's "look" — he was hired to be a 
production artist. This leads us to 
another seemingly reasonable idea: 
hire an art director (let's call her Ann). 
If someone can be responsible for art 
direction, it relieves the pressure on 
Albert and Dave, and Pam has some- 
one to trust. Another important 
advantage is that Pam can use Ann's 
strong resume to make the whole pro- 
ject look better, which will help get 
internal support for better budgets, 
marketing efforts, and so on. 

But, of course, there are drawbacks. 
First, we have the obvious problems 
that come with a larger team (more 
complex communication and greater 
cost, to name just a couple). Game 
developers are well aware of how 
nightmarish huge projects can be, and 
it should be obvious that our little 
threesome is not predisposed to throw- 
ing people at a problem. But perhaps 
Ann could work only part-time, keep- 
ing costs low, and if she's good, the 
other problems may be minimized. 

The real problem is rinding someone 
good. In this case, "good" means an 
experienced, available, affordable art 
director who can also walk into this deli- 
cate situation and actually improve 
things. It would be very easy for Ann to 
give Albert orders that accidentally or 
carelessly conflict with Dave's previous 
direction, which is a quick road to dis- 
trust (and thus disaster). Art directors' 
jobs require debating with programmers. 
Because Dave is "in charge" in addition 
to doing the programming, the art direc- 
tor's going to have to be a darned good 
communicator to get Dave's trust and 
respect, earn Pam's confidence, and keep 
the art quality high, all without stepping 
on anyone's toes. 



Solutions 

Yuck! What a bunch of weak 
options. None of them is the nice, 
neat happy-ending choice for which 
we'd all hope. Let's step back and ask 
what our beloved team could do to 
make the whole situation better. 

They need to realize how important 
this issue is, and put a lot of effort into 
permanently solving the problem. That 
means understanding the actual risks: 
damaging goodwill and thus, the pro- 
ject's future, as well as potentially hav- 
ing poor artwork. 

Ideally, you don't have to choose, 
but I believe a few talented, coopera- 
tive, focused people with a little money 
produce better products than a team 
that has a pile of cash and a bunch of 
uncaring, uncoordinated workers. 
That's why creating and preserving 
goodwill is such an important skill. 
Unfortunately, goodwill is incredibly 
delicate. It's part of both Pam's and 
Dave's jobs to protect the project 
against such disaster. 

How would awareness change the 
situation? Here's one possible outcome: 
Pam starts by taking a close look at 
what, exactly, worries her. What would 
be satisfactory art quality, and what 
would not? What kind of proof will be 
enough, given that she knows she's not 
an art director? If she's really good, 
she'll also probe for underlying "icky 
issues" — unpleasant but true motiva- 
tions for her concern. Is the problem 
really art quality? Perhaps she's sub- 
consciously looking for some direct 
control over production. Or perhaps 
she's interested in forming a line of 
communication around Dave because, 
deep down, she doesn't trust him com- 
pletely. Once she addresses these ques- 
tions honestly with herself (and let's 
assume that she's comfortable with her 
own motivations), she will use those 
answers to set concrete, achievable 
objectives. 

Next, Pam meets in person with 
Dave and explains exactly what wor- 
ries her and precisely what proof of 
quality artwork would make her com- 
fortable. She might carefully use other 
products as artistic references (some 
developers hate this, but it works), 
such as "I think we need terrain like in 
Magic Carpet — see this screenshot? 
Like that, but maybe simpler — and 
with animation as good as Road 




Rash." If she 
uses reason- 
able refer- 
ences, Dave 
will likely be 
open and 
grateful for a 
specific 
goal rather 
than a 

vague, unsolvable concern. Again, Pam 
must be very careful not to ask for 
unreasonable goals such as "Art that is 
better than Riven, but real-time, and 
with flowing hair!" This will definitely 
not impress Dave, and may well lead 
to serious conflict. After this has been 
defined, Pam and Dave have to agree 
upon who approves the art. This is 
really Pam's decision — if she feels 
comfortable that Dave understands 
what she wants, she will ask him to 
decide. Otherwise, she'll put off the 
decision until she knows whether or 
not Albert can handle it. 

Once Pam and Dave agree on what is 
"good enough" art quality, they'll 
explain it to Albert (who will find their 
explanations of quality artwork to be 
overkill). Pam and Dave together will 
ask Albert to show that he can provide 
that quality of artwork. As Albert pre- 
pares samples, they'll stay in close 
communication, exploring what is rea- 
sonable and reassuring each other that 
they're all striving for the same thing: 
the best possible product, in whatever 
way they can. 

After Pam and Dave take a look at 
Albert's artwork, it's decision time. 
First, they'll decide whether or not 
Albert is capable of art direction. If 
they don't agree, Pam's got a serious 
problem. She may well decide to use a 
different developer rather than attempt 
to patch such a major rift. 

That should give you the idea. The 
decision process would continue in 
this way until they are all satisfied that 
the game is good enough or they give 
up on the project (a perfectly reason- 
able option — better than wasting 
time, money, and effort if the project is 
essentially flawed). 

It's tough creating good games, and 
technical challenges are only part of 
the problem. I write about it often 
because I think that we all need more 
of this "psychological" problem-solv- 
ing. Tell me what you think at 
column@vectorg.com. ■ 
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o get the most bang from your prototyping buck, consid- 



er these two essential guidelines: Prototype Early and 



Prototype Often. By definition, prototypes allow you to demon- 
strate new ideas in a rudimentary form, examining and consider- 
ing different possibilities before committing resources to those 
ideas. Waiting until the release of your alpha to test your first pro- 



totype is generally a useless gesture: your alpha represents most of 
your final game. If you discover at this point that the design 
requires a major overhaul, it will probably be too expensive to 
undertake. Instead, create your first prototype for the initial 
design meeting — and then never stop. According to Rand Miller 
of Cyan, "Whether you're showing it to someone or just using it 
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FIGURE 1 . As the game develops from stage to 
stage, the cost of making a change increases 
exponentially. 



FIGURE 3 . Cyan used flowcharts like this one from 1994 to 
refine Riven's more complex story structure. 



for yourself, the interesting thing 
about a prototype is that the more 
feedback you get, the easier it is to fix 
things before you lock them down" 
(Figure 1). In light of these principles, 
this article will take an in-depth look at 
cheap — and not so cheap — prototyp- 
ing techniques used to design Riven: 
The Sequel to Myst. 

During the early days and weeks of a 
project, the design is small and proto- 
types are simple to make and revise — 
clearly, most of your prototyping 
should be done at this point. Think of 
your design process as a spiral that 
iteratively visits the four process quad- 
rants of Design, Prototype, Test, and 
Learn, starting with your kick-off 
meeting at the center and time (and 
costs) increasing outward with each 
loop (Figure 2). The more cycles that 
you complete earlier in development, 
the tighter the spiral becomes and the 



Prototyping for 5-D Garnet 
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more money 
you save. 
Since each 
iteration rep- 
resents the 
validation of 
good design 

ideas and the elimination of bad ones, 
you can be assured that your project 
matures on the inherent merits of its 
design and not merely on its creators' 
enthusiastic ideas of what it should be. 

Obviously, elements such as art 
direction and code performance won't 
be prototyped until later in the design 
process. However, general game con- 
cepts, basic character interaction, and 
what the player will experience can — 
and should — be worked out before 
you've purchased your first pixel. Since 
you haven't yet made a design commit- 
ment, your prototypes can be very 
rough and cheap as you work out these 
important details; later 
on, as your designs solid- 
ify and become more 
complex, they will 
become much harder to 
prototype and test. 



FIGURE 2 . The Design Spiral: separate the good 
ideas from the bad early in production while they 
are still cheap to fix. 



Prototype the Concept 
and Story 

All great adven- 
ture/mystery games 
focus on the story. Prior 
to puzzle design, you 
should explore your 



game's structure and the player's goals. 
Your new world won't have an inte- 
grated adventure until it has plot twists 
and major characters. Nonviolent 3D 
games are driven by exploration; with- 
out a unifying narrative, the experi- 
ence is of walking from one obtuse 
puzzle to the next. 

Simple, one-page flowcharts excel at 
prototyping during this stage because 
they hold just enough detail to represent 
the story's structure. For Riven, designer 
and co-director Robyn Miller created 
flowcharts to map out the different end- 
ings. These flowcharts offered Riven's 
designers the flexibility to depict the 
consequences of the player's actions and 
the multiple ways to end the game 
(Figure 3). Later on, when the Cyan 
team designed the puzzles and environ- 
ments that surrounded these plot points, 
the skeletal flowchart prototype was eas- 
ier to use than a 40-page treatment. 

Once you've established the outline 
of the story, your 3D game needs a 
place where the action happens. As he 
did for Myst, Robyn sketched maps of 
the different islands on graph paper, 
labeling the paths and buildings that 
the player would encounter along the 
way. During initial game design meet- 
ings, Robyn could erase and redraw as 



Nicole Lazzaro, president ofXEODesign Inc. and production manager for the French and German versions of Riven, has for eight 
years combined her knowledge of cognitive psychology, video, origami, HyperCard, and the Xerox machine to create customized 3D 
environments. XEODesign provides design services to numerous companies including Broderbund, Mindscape, and Maxis. For more 
information on prototyping and a schedule of upcoming seminars (including this year's Computer Game Developer's conference) 
visit www.xeodesign.com or send e-mail to nlazzaro@xeodesign.com. 
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much or as little as required during the 
evolution of the design. 'There was an 
awful lot of scribbling, scratching, and 
erasing at those first meetings, " 
remembered Robyn. "But by the end of 
a few weeks, we had recorded the basic 
game play for the world, though it 
wasn't too pretty/' 

The overhead view concentrated 
design on the location of the puzzles in 
each environment and how those puz- 
zles related to the others on the five 
islands. Done with pencil on graph 
paper, conundrums such as the loca- 
tion of the waffle iron puzzle could be 
planned with a minimum of fuss 
(Figure 4). If Cyan's artists had already 
modeled the islands on the computer, 
those same changes might have taken 
weeks instead of minutes. Pencil 
sketches of the big picture kept the 
ideas flexible and easy to change. 



Prototype the Fun 



To invent a new game paradigm, 
prototype the fun. In order to go 
where no other title has gone before, 
you may need to experiment with the 
game play outside of the computer — 
especially when your game's technolo- 
gy hasn't been invented yet. Putting 
your design on the computer before 
the basic game concepts are in place 
increases the likelihood that the end 
result will resemble someone else's 
good idea. Leaving behind the elec- 



tronic limitations of a flat screen and a 
mouse frees you to discover interesting 
interactive possibilities. 

Ideally, prototyping game play 
should spawn "outside the box" think- 
ing; knowing what makes an activity 
entertaining will help create its ana- 
logue within the game. Get the creative 
juices flowing by using a number of dif- 
ferent prototyping tools. Don't limit 
yourself — a video camera, a cell 
phone, an office cubicle, a roll of butch- 
er paper, and even a toy car can assist in 
prototyping (Figure 5). Your imagina- 
tion and creativity will take care of the 
rest. "If you're talking about prototyp- 
ing," said Robyn, "your tools should 
allow you to be flexible. They should 
allow you to change things right up to 
the last minute." Just remember that 
the cost of those changes increases as 
the design progresses (Figures 6 and 7). 

Given the fact that Riven' s primary 
storytelling relationship is between the 
player and the environment, Cyan's 
designers prototyped 
the fun before creat- 
ing any art by host- 
ing virtual tours of 
the Riven maps to 
test the basic out- 
line of the game. 
"We sat down with 
people from the 
company and ver- 
bally walked them 
through the game, 
told them what 



they saw, and asked them what they'd 
do — almost a role-playing kind of 
thing — before there were visuals," 
Rand explained. 

This verbal prototyping provided 
flexible and cheap feedback on story 
and game play because all that was 
necessary were maps and puzzles ideas. 
"In my mind," said Rand, "it was more 
to see how people responded to explor- 
ing this place... you're surprised a lot 
of times by what people get and what 
they don't get." Before designing any 
of the art, Cyan's creative team needed 
to know what puzzles people would 
find interesting, which ones were too 
hard, how players built the story from 
the environments, and what sorts of 
actions players found fun to do. 
Because they role-played the puzzles, 
Riven's designers could see in the play- 
ers' faces what was fun about exploring 
and discovering the story and world, 
and they could pursue ideas created 
spontaneously by the group. Robyn 





FIGURE 5 . Playing games away from the computer can 
prototype what makes something fun. 



FIGURE 4. The power source for the Fire Marble domes 
always involved the waffle iron puzzle, but its location 
changed from the Book Assembly Island to Temple 
Island. 



frmaJi Fast 



FIGURE 6 . Prototyping tools that cannot represent a lot 
of detail are generally faster than those that can more 
accurately represent the final product. 
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Production Goal: Prototype Art and Video Production Techniques 
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FIGURE 7. Asa game goes from concept to design to product, different aspects 
of the design require different prototyping methods. 



remarked, "It worked really well, and 
we did it earlier on Myst, too. At least it 
gave us an idea that what we had 
designed was going to work." 



Prototype the Art 

After outlining the essential story, 
location, and game play, the 
focus of your design should shift to 
what the player will see and hear. 



Rough line drawings can refine how 
objects and terrain will work together 
to build the environment and story. 
At this stage, concept sketches on 
paper will help you explore ideas 
more quickly and create a consensus 
of the story world to be built in 3D 
(Figures 8 and 9). 

Low-resolution prototypes have two 
benefits: they are quicker (and thus 
cheaper) to make, and they focus dis- 
cussion on broad concepts rather than 



on details such as color and texture 
maps (Figure 10). By limiting the 
number of items and keeping the 
drawings rough, you can make 50 
black and white sketches for the cost 
of a single RGB image. 

Unlike paintings in a museum, game 
art unfolds in response to the player. 
As Riven's designers discovered, paper- 
based sketches of objects and terrain 
didn't provide enough feedback when 
the game design focused on player 
interactions; these elements required 
new prototyping methods. 

Just as role-playing can prototype 
player interaction from maps, interac- 
tive sketches and storyboards make 
designing art that responds to player 
behavior much easier. Scanning story- 
board-style sketches into the computer 
and making them interactive is an eco- 
nomical way to create useful 3D envi- 
ronments early in the prototyping 
stage — line drawings in HyperCard are 
easier to change than Softimage-ren- 
dered images. With an electronic story- 
board, the designer can click through 
the environment and make changes as 
easily as erasing lines on paper. 

In Riven, game play changed the 
look and function of one particular 
water-filled room several times during 
art production; at one point, even the 
waffle iron puzzle floated here. 
Evolving the design after the room 
was finally rendered required throw- 
ing out several screens, updating the 
geometry, adding new textures, 
shaders, and lighting, and rendering 
new art (Figure 11). By comparison, 
switching between different concepts 
while still in sketch form would have 
sacrificed a few pieces of paper and 
some pencil lead. "Next time," said 



1 





FIGURE 8 . Richard Wander Wende started the design for Gehn's inkwell by drawing many bugs. 
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FIGURE 10. In this Riven forest, rough art quickly prototypes the relation- 
ship between the player's path and the trees. 




FIGURE 9. A hand-drawn sketch at this 
resolution can be created faster than 
working with a 3D modeling package, 
even in wire frame. 



Robyn, looking back, "I personally 
would want to set up the whole thing 
with storyboard-style sketches, so you 
could have a playable or semi-playable 
game in rough-sketch form. I think it 
would save time in the end because 
we spent so much time changing this 
thing, which was for naught because 
we threw stuff away as we changed it." 

Rand Miller and designer and co- 
director Richard Vander Wende, how- 
ever, disagreed somewhat with Robyn 
and cautioned that too much detail in a 
rough-sketch prototype interferes with 
the final art direction. As Richard 
explained from his previous experience 
in animation, "Many painters and illus- 
trators I know will produce preliminary 
sketches, thumbnails, or even drawings. 
Quite often, they adhere strictly to 
those drawings, and the final version 
lacks a certain freshness. [With Riven], 
there was an element of spontaneity — 
we didn't always know how it was 
going to work. We weren't always try- 
ing to copy exactly some sort of proto- 
type version, which I think was great." 

Prototype Medio Production 
Techniques 

With Riven's style of interface, 
the settings for the 3D camera 
position, height, tilt, and viewing 
angle all determine what the player 
sees. Done well, a sequence of still 
screens creates a sense of motion that 
draws the player in; done poorly, how- 




FIGURE 11. This room holds a submersible elevator and went through 
several artistic and functional changes. Changing the purpose of this 
room during the rough sketch stage would have involved fewer produc- 
tion hours — or days. 



ever, it invites player confusion that 
even wonderfully rendered 3D art can- 
not dispel. As Richard pointed out, 
"You just can't put the camera where 
the mannequin's eyes would be all the 
time. More often than not, the camera 
needs to be cheated one way or anoth- 
er to allow you to see more of the stuff 
that you would naturally be focusing 
on — sometimes in small rooms, it's 
even pulled back through walls to cre- 
ate a wide enough view to contain 
everything of interest." 

"Although it seems fairly natural 
when you click," said Rand, "we didn't 
take for granted how much you move 
— a lot of work went into how far we 
set the next camera position and what 



angle it would be placed at, and how 
much you would see out of the corner 
of your eye to inspire a turn." 

Although the design team didn't cre- 
ate full storyboards for Riven, they did 
develop an ingenious world assembly 
tool in HyperCard called WorldStarter, 
which made positioning the camera in 
the computer-generated models easier. 
To save time and to get more itera- 
tions, they started with wireframe and 
flat-shaded views along a path or 
around a room and then modified the 
camera position and angle until the 
navigation looked smooth (Figure 12). 
Because the artists could click through 
the images just as a player would, they 
could easily grasp how it felt to move 
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through the space (Figure 13). By build- 
ing Riven in thisfashion, subtle prob- 
lems became apparent at an earlier 
stage of the art production. When 
inconsistencies arose, the designers 
could make changes and tweak more 
confidently than they would have oth- 
erwise, as their prototypes provided 
more context. As Rand remarked, 
"Probably most peopledon't realize the 
extent to which every camera position 
was cared for there, and what we went 
through to create them." 

In time, more screens were added. 
Detailed renders replaced theflat-shad- 
ed views (Figures 14 and 15). "If we 
had pictures that we needed to add," 
Rand said, "we'd walk through to that 
area, get to that dead end, and then 
just start adding in the new pictures. 
Since thefeedback's immediate, we 
weren't afraid to tweak things, which 
was very important to us." 



Prototype Terrain 

All too often, production proto- 
types show you what not to do. 
For Myst, Robyn created a grayscale 
topographical map for each island 
that was then extruded in Strata, with 
the lighter-shaded areas being higher 
in elevation than the darker ones. He 
considered using the same process for 
Riven, but he had some concerns: not 
only were Riven's islands much bigger 
than Myst's, the puzzles required 
more precise control of the elevation 
(Figure 16). 



Asa production test, Robyn modeled 
Gehn's Survey Island in clay and 
bought a 3D pen to digitize its contours 
(Figure 17). "The only way we could get 
it to look neat on the computer was to 
use tons of geometry, so much so that 
the computer wasn't handling it very 
well," recalled Robyn. "Wethought 
that if we gave the rock more of a styl- 
ized look, we could use a lot less geome- 
try. But when I began to digitize the 
thing, it wasjust a complete failure. It 
wasjust horrible working with the digi- 
tizer; it wouldn't read the points at all, 
or it wouldn't put them together cor- 
rectly." After struggling with theclay 
model, the digitizing effort was shelved, 
and Robyn and Richard went back to 
th e gray seal e extrusi on s. 



Scale Models for Actors 

Sizing models created by different 
arti sts so th ey I i n k togeth er seam- 
lessly is but onech alien ge of building a 
3D space. It was for this reason that 
Cyan added another valued team 
member: Harold (Figure 18). "A long 
time ago, we had created a very simple 
mannequin that we would put into our 
environments to make sure that the 
scale felt right," said Richard. "We built 
all of our environments to scale, but in 
addition to that, just putting a person 
there — or a computer-generated 
model of one — really helped out." 
Harold was soon cloned and his exper- 
tise shared among all of the artists. 
Being a virtual six feet in height, he 



could be brought on the scene to test 
the player's line of sight, as well as the 
scale of the surrounding terrain. With 
al I of the separate objects that were 
imported into the model to create an 
environment, the Harold prototype 
proved to be valuable aid in keeping 
everyone's work in the same ballpark. 



Position Lights, Camera, and Talent 
for Bluescreen 

Live action in 3D computer graph- 
ics requires precise positioning of 
the cameras and lights used to photo- 
graph the actors against a bluescreen 
background. In most cases, you can 
speed the production process by 
preparing your models ahead of time 
and using them to prototype your 
final composites while on the set and 
before shooting a single frame. Cyan's 
designers brought to thestage their 
Softimage models on an SGI and a 
Macintosh for video compositing. 
Having built everything to scale 
before the shoot, they spent most of 
the day setting up the lights and cam- 
era positions to match those in the 
computer-generated background — 
and discovered that the integration 
would work better than they had 
imagined. "Because we had built our 
models to scale and we had lighting 
objects in thecomputer," commented 
Richard later, "we knew where the 
light sources were: they were six feet 
off the floor and were spaced exactly 
five feet apart. We could duplicate 
that on the set and that worked really 
well." Using their models for refer- 
ence, a video frame was placed over a 
still from the model. Through this 
iterative prototyping process, the cam- 
era position, lens angle, and lighting 
were adjusted until theeffect was 
seamless. 



Prototype Animations 

Depending upon your needs, you 
can prototype animations very 
cheaply by creating story boards that 
can be used by themselves or scanned 
into a computer for simple animation. 
If your team is beyond the story board- 
ing stage, you can mock up your envi- 
ronment in a software package that 
yields low-resolution walkthroughs, 
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such as Virtus Walkthrough or the Quake level 
builder Deathmatch Maker. Both of these 
packages quickly set up simple texture geome- 
try that players can walk through. As your ani- 
mations become more polished, you can take 
advantage of some of the simple visualization 
tools that most 3D packages contain: wire- 
frame animations can be played in real time, 
and for more detail, flat-shaded animations 
will render in a fraction of the time required 
by full versions. You can use these low-resolu- 
tion images as references for making changes 
before the final render, which may take many 
hours or days to complete. 

"Softimage's tools are really flexible, and are 
one of the biggest strengths of that whole 
package I think," said Richard of the 3D appli- 
cation used to create Riven. "A lot of these 
animations were so complex in terms of the 
geometry that we knew we were only going to 
have one shot at fully rendering this thing — 
it was just going to take so much time. So we 
really tried to make sure that we had seen it as 
many times as possible in its various primitive 
stages, including wireframe and shaded 
views." For example, even with four SGI 
servers, the submarine adventures at the bot- 
tom of Jungle Island Bay lived in the queue 
for months because the atmospheric shaders 
and reflections caused the animations to creak 
out very slowly, frame by frame. 

The fast playback of the wireframe anima- 
tions allowed Riven's designers to adjust the 
player's experience before committing to a 
lengthy full render. Rand explained: 
"Especially for the major animations, we 
would always render flat-shaded views — or 
we would render out the wireframes so that 
they could play at full speed, just so we could 
see the action and make sure. Even though it's 
a subtle effect, if you get to the end of that 
lumber car ride and there is no pause before 
falling out of the bottom of the car, it just 
doesn't feel right." 

Prototype Navigation: Click-Through or 
Virtual Bubble? 

Early on in Riven's design, the Cyan team 
prototyped different navigational systems 
by doing some test renders. These production 
prototypes compared the click interface style 
from Myst with several that provided more 
freedom of movement, such as QuickTime VR. 
The designers found that while a VR experi- 
ence more closely resembled moving through 
a real world, they lost control of how the clues 
in the environment were revealed to the play- 
er. Richard remarked, "Since the presence of 
other characters in these games is still pretty 




FIGURE 13. Artists could make changes as they walked through the 
world, even if that world was a low-resolution one. 
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FIGURE 14 . Interactive walkthroughs provided feedback on how the final 
art would look together. 




FIGURE 15. Using HyperCard artists could quickly define and modify but- 
tons to fit a particular screen and drag new screens from a list into the 
fields below the view area. 
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FIGURE 16. This grayscale map of Riven' 's Temple 
Island shows the higher elevations in lighter colors. 
The colored areas indicate areas to be kept at the 
same elevation. 



slight, the primary relationship is between the participant 
and the environment. So we tried to imbue that environ- 
ment with as much meaning as possible to maximize the 
richness of that relationship between the environment and 
the participant. If you're just running through the game and 
not seeing things and not hearing things, then you're cheat- 
ing yourself." 

The step-through interface created a more contemplative 
pace, encouraging the player to look for clues. 'The click- 
through interface, to a certain extent, slows you down and 
allows you to digest what you're seeing and what you're hear- 
ing better than if you were just running through it at 
marathon speeds," said Richard. Riven's designers wanted 
players to really look closely at the environment around 
them to notice the subtleties. By comparing some tests in VR- 
type environments with the more traditional click-through 
interface, they decided that a virtual bubble would constrain 
their game design too much. The primary drawbacks were: 

1. It degraded quality of the art (because of compression or 
rendering on the fly). 

2. It led to a loss of control over where the viewer looked (as 
if one were making a film without edits). 

3. It did not support multiple states. (For example, an open 
and closed door required two different bubbles instead of 
just two different screens.) 

4. The VR interface encouraged the player to speed through 
the terrain, emphasizing the speed at which they could 
solve the game's puzzles. (Click-through interaction 
slowed the viewer down, emphasizing the importance of 
observing.) 

Being Flexible versus Being Finished 

Prototypes are guide books rather than detailed road 
maps. Designs can change frequently, even at the end of 
the title's development. 'The one thing I have to say about 
the way we did things was that it was a lot of flying by the 
seat of our pants," said Richard. 'The fact is that you can have 
stuff planned out on paper, but making it real and detailed 
and complex and functional often necessitates changes and 
adjustments in the contiguous objects and spaces." No matter 
the extent of your prototyping efforts, recognize that story- 
boards or even the "final script" never matches the release. 
"Flexibility is what allowed us to keep tweaking and twisting 
and making it better," said Robyn. "At the same time, flexibil- 
ity is what prevents you from ever being done. So as long as 
you understand that and can work within those constraints, 
you can get the best possible production available given the 
amount of time and money you have." 

Prototype to prepare your ideas — seed the creative terrain 
and make it fertile. Use design prototypes to become familiar 
with the space, so that when production starts and design 
decisions lock down one by one, your team will understand 
the opportunities and share the same vision. ■ 

Special thanks to Rand and Robyn Miller, Richard Vander 
Wende, Bonnie Staub, and Richard Corley for their help, hospi- 
tality, and access to Riven's prototypes. 




FIGURE 17. Robyn created a clay model of Gehn's 
Survey Island in the hopes that it would be easier to 
digitize than to extrude from grayscale. 




FIGURE 18. Harold, Cyan 's cyber stunt person, ( whose 
head and shoulder can be seen in the lower right cor- 
ner) provided reference for the scale of models and 
camera placement. How big were objects compared to 
Harold? What could Harold see from different places 
along the path? 
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E>ring environments that provide visual 
presentations of a program structure 
that are more conducive to a creative 

■ L state of mind can make a dramatic 
k difference in enhancing your 
L creativity. Years back, I 



remember sitting my three-year-old son on my lap while at 
the computer, showing him what I had just made using 
HyperCard and asking, "What would you like now?" I imple- 
mented his demands then and there. The results were way 
beyond what I could have imagined on my own. Apparently, 
Craig Hickman built Kid Pix the same way. Of course, even- 
tually we had to rewrite everything in a real programming 
language, but for project take-off, HyperCard was fine. 

More recently, fun-oriented development has become a 
nearer reality with the advent of mFactory's mTropolis, now 
under the wing of Quark. Note that I haven't said the fun 
has arrived. But mTropolis certainly gives us a window on 
what the future will bring. 
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Enter mTropolis 



As a beta site for mFactory, I've been working with 
mTropolis since it's alpha stages five years ago. I've 
used it to create several major prototypes and lots of experi- 
ments and toys. mTropolis has an attractive feature list, 
including a true object-based structure with its own 
extendible object model (the mFactory object model, or 
MOM). It compiles impressively efficient code. The graphi- 
cal drag-and-drop interface provides a clear abstraction of 
what's going on, at least in general terms. It's cross platform. 
It has convenient ways to manage and relink your resources. 

But the most empowering feature is something called 
BOP. That's how visionary Norm Gudmundson, the creator 
of mTropolis and chief engineer of mFactory, refers to his 
paradigm for software development, Behavior-Oriented 
Programming. 

BOP! 

For a better concept of what Behavior-Oriented 
Programming provides and how to take advantage of it, 
I'd like to use a parallel to our concept of the universe. At 
one time, everyone thought of the solar system, and of the 
universe, as having one absolute center. Whether that was 
the earth, the sun, or somewhere else, was subject to debate. 



GAME DEVELOPER MARCH 1998 



http://www.gdmag.com 



I 



But this absolute center could only be in 
one place. 

Then Albert Einstein came along and 
proposed a new way of looking at things. 
Now, as his students have explained, 
anywhere that you wish could be the 
center. You just need to create an appro- 
priate model. 

Similarly, procedural code is all about 
getting from a beginning to an end. The 
procedure that takes you there is the 
absolute center of everything, branching 
out in routines and subroutines, but all 
in one path with one vortex. 

Object code begins to break out of that 
paradigm, but it reaches it fruition with 
BOP. Here, every time you work with 
any of your objects, you must see all of 
the rest of the world that you've created 
from the perspective of that object. How 
will that object react to the rest of its 
world? What will it do with the informa- 
tion that it receives from "out there"? 
What will it tell its world about its own 
internal state? In fact, every object 
becomes the center of its universe. 

Reusability is the most salient advan- 
tage of BOP. A BOP programmer ensures 
that all of his objects are as self-sufficient 
as possible and avoids being context-spe- 
cific at all costs. He does this principally 
by designing his objects for as generic an environment as is 
practical and by establishing consistent protocols in all his 
worlds. An object that sends messages that mean one thing 
in one world and something else entirely in another is not 
very valuable. A valuable object operates similarly and pro- 
vides meaningful data in a wide variety of contexts. 

Adaptability is another point chalker for objects. A "rigid" 
object, such as a scroll bar that remains the same size in 
every environment, is a rather useless asset. A good object, 
then, receives messages about its environment and knows 
what to do with them. A good world, it follows, is one that 
provides its objects with meaningful information. 

Complicated objects that cannot be broken into smaller, 
self-integrated components are a pain — a pain to work with 
and a pain to debug. A BOP programmer starts off by acquir- 
ing many small and simple self-reliant objects. Once he has 
a rich library of those basic components, he can carefully 
build them into larger "organisms" that have more specific 
functions. If he builds them well, another programmer will 
be able to use them in his worlds without having to know 
much about their inner contents. 

BOP is a realistic simulation of the real world. Imagine how 
your world would be if it had been made by conventional pro- 
grammers. From a passive viewpoint, everything might look 



mFactory s Official Position on 3D 




asked Norm Gudmundson, creator 
of mTropolis and chief engineer at 
mFactory, what he was planning 
to do about 3D in mTropolis. 
Here's the e-mail response: 

"mFactory has always been very inter- 
ested in integrating 3D technology into 
mTropolis. Unfortunately, when we tried 
that a couple of years ago, there was no 
standard 3D technology to build a suc- 
cessful twitch 3D game (in my opinion at 
least). This was because most successful 
twitch 3D games use a proprietary 3D 
engine or a heavily modified standard 
technology designed specifically for the 
game. It's my feeling that 3D twitch 
games will always exist on the very edge 
of the technology wave, just beyond 
where mFactory can reach. 

"Does this mean that mTropolis will 
not incorporate 3D technology? No way! I 
think real-time 3D is strategically impor- 
tant to all 'software solution composers' 
such as mTropolis. However, the objec- 
tive of 3D in mTropolis will be to stress 
real-time 3D simulation and possibly pro- 



totyping 3D games, not to act as a 3D 
twitch game development environment. I 
think we will all have to leave that to the 
whiz kids hacking away in the back 
rooms. At least for a while yet. 

"With real time 3D simulation integrat- 
ed into mTropolis, BOP could really take 
off. After all, the whole point of BOP is to 
break down software problems into the 
fundamental components we find in the 
"real" world. I can't think of a paradigm 
that mates as perfectly with real-time 3D 
as BOP, and since mTropolis is the only 
environment that uses BOP so far, the 
marriage just has to be made." 

I also asked Norm if he thought that 
those "on the edge" 3D programmers 
would be able to extend mTropolis's 
future 3D capabilities using MOM. He 
was honest and answered that he can't 
know until the alpha and beta phases of 
3D integration. But, "mTropolis has 
always stressed the need to extend its 
supported features and 3D would be no 
exception." 

— Tzvi Freeman 



O.K. But then, let's say you grab a bucket, walk over to a pond, 
and lift out some water. Within the context of the bucket, the 
water would probably behave entirely differently than it did in 
the well. Bring the bucket into your kitchen, and it may just 
suffer a fatal error and crash your entire reality. 

We generally see our world as being made of many pieces, 
each having their own properties and interacting with each 
other in specific ways. BOP means thinking about your pro- 
ject in the same way. 

True BOP mastery still eludes me, but in many instances, 
I've managed to create a wonderful and valuable animated 
object with multiple behaviors in one project, dragged and 
dropped it into an entirely different project, and after a few 
minor tweaks, have it do all the same tricks in an appropri- 
ate mode for its new environment. mTropolis 2.0 has made 
some important fixes that make such moves more reliable. 

Rocket BOP 

This is not a tutorial, just a loose description. I'm using a 
Power Macintosh with mTropolis 2.0. I've just opened a 
new project window. That three year old mentioned above, 
who acted as a lap consultant on my first children's game, is 



Tzvi Freeman teaches Multimedia and Game Design at the University of British Columbia Multimedia Certificate Program. He has 
designed several commercial games and acted as a consultant on many more. He is interested in hearing your comments at 
tzviF@aol.com. 



http://www.gdmag.com 



MARCH 1 99 8 GAME DEVELOPER 



SNEAK PEEK 




FIGURE 1 A . The Layout Window in edit 
mode... 



now ten. He falls into my home office 
at 3:20pm, looking for what's cool 
today. Great, just in time to help with 
this article. 

When asked, "What do you want to 
create today?" his response is a typical 
10 year old's unintelligible, hyper-bab- 
ble, which I interpret as, "I feel like 
making things blow up." 

My son reminds me that we have a 
wonderful outer-space-object exploding 
animation that works well with a small 
explosion sound effect he created. I 
have that object exploding in another 
project — all the necessary behaviors 
are already set. So I open that project, 
find that object, and drag and drop it 
into my new project. Now all it needs is 
something to send it a message that 
says, "explodelnSpace," and it'll go up in 
solar luminance, leaving behind a 
burnt crust. 

I need something to attack the 
space object. The CD that mTropolis 
comes on contains a few libraries of 
ready-made behaviors, as well as 
some objects that use them. There's 
a rocket in one library that's pro- 
pelled by the arrow keys. It also has 
momentum and drag built in. 

I drag and drop the rocket into 
my project (Figures 1A and IB). 
Then, I drag a small icon from the 
Modifier Palette — this one is called 
the Collision Modifier — configur- 
ing it with a few mouse clicks 
(Figure 2). I set the rocket object's 
behavior so that whenever it hits 
another object for the first time, it 
will tell that object explodelnSpace 
(Figure 3). 

I've just dragged two objects out 
of two entirely different projects 
authored by two different people 
who are in no way coordinated with 
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FIGURE 1R. ...and in run-time mode. 



each other. If they are well-built 
objects that follow all the BOP 
guidelines, they will work together and 
we'll have an explosion on the screen. 

Hitting one stationary object in open 
space doesn't quite compete with the 
neuro-traffic in my kid-consultant's 
brain. I dig up a neat random-motion 
behavior to drop into our space-object, 
setting it to terminate when the 
explodelnSpace message arrives (Figure 4). 

For even more excitement, I repeat- 
edly [Option] -drag the object to make 
multiple copies. Since the behaviors 
are all "aliased," I can still modify the 
behavior of all of them by modifying 
any one of them. But since the vari- 
able that sets velocity is specific to 
each object, I allow the consultant to 
adjust each one to a different setting. 
He also adjusts size and color for each 
object, no typing necessary. Total time 
to construct this prototype: approxi- 
mately 15 minutes. 
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FIGURE 2. Dropping a new Behavior 
Modifier from the Modifier Palette into my 
rocket. 



BOPping the Head Against 
the Wall 

As can any technology, 
BOP can be quite frus- 
trating. The good news is that 
most of the hassles are things 
that have visible solutions to 
them. Here are a few of my 
major gripes: 

The first two are problems 
with the scriptor interface. 
It's wonderful, especially for 
chronic typo-slobs such as myself, to 
be able to just drag, drop, and click an 
entire program together. But the con- 
venience — at least in its present incar- 
nation — doesn't come without severe 
compromise. For just one example, 
double-clicking, typing, then closing 
20 icons to adjust 20 variables can get 
kind of tedious — apart from the fact 
that you can't view them all as one list. 
Of course, you can use a List Modifier 
to set them all, but that was imple- 
mented as an awkward afterthought, 
and it's very clumsy to use. 

The Structure View provides a kind 
of outline of the entire program, simi- 
lar to an indented outline that you 
might use for an abstract of an article 
you'd like to write, or the contents of a 
book. Establishing good naming con- 
ventions for yourself helps make this 
view all the more meaningful. The 
problem is that there's only so much 
that you can see on a single screen. In a 
long or complex project, the script 
view resembles watching a football 
game through a tiny crack in the 
fence. mFactory could easily allevi- 
ate matters by allowing multiple 
views of the same window, and at 
the very least, providing printing 
capabilities. A print out could pro- 
vide detailed information that's not 
available in the structure window. 

Speaking of reviewing your script, 
whatever happened to programmer's 
comments? The only place for these 
are in the miniscript modifiers. If the 
Structure View is meant as a window 
on your project's architecture, then 
why can't I annotate it? 

A Behavior Modifier has its own 
view — quite a clever one. I won't 
bother with all the details here, but 
the window is too easy to clutter 
and, again, has no place for com- 
ments other than in miniscript mod- 
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FIGURE 3 . Selecting a message for 
the Collision Modifier to send. 



ifiers. Going into a complex behavior 
created by even the best mTropolis 
designer and trying to adapt it to your 
project can be a nightmare. Yet that 
capability should be one of the salient 
features of the tool. 

As far as problems inherent to the 
concept of BOP, they fall into two cate- 
gories: issues associated with stereo- 
typed behavior, and the extreme diffi- 
culties that are loaded into the 
programmer's brain in conceiving all 
the dynamics of his creation. 

Consider my rocket zooming about 
telling everything it hits to explodelnSpace. 
That's fine when there's only a handful 
of objects and most of them are respon- 
sive to that message. But, just as in our 
reality, not everyone wants to hear you 
say, "Have a good day!" every time you 
bump into them. In most games, such a 
behavior could have undesirable conse- 
quences. For one thing, the CPU is over- 
loaded with processing this message and 
all the instances of it as it travels down 
the parent-child hierarchy- tree. 

One solution is to make your mes- 
sages more discerning and specific. This 
message's transmitter could get some 
information about an object before 
engaging it in conversation. This infor- 
mation would help the transmitter 
determine whether the object might be 
responsive or not. But then, you're just 
trading off one overhead for another. 

mTropolis allows you to limit the 
range of a message's transmission. You 
can send it to the whole project, to an 
object's parent, to siblings, or only to a 
specific object. You can even stipulate 
that this message doesn't "cascade" 



down the hierar- 
chy. In my expe- 
rience, however, 
these solutions 
severely compro- 
mise the reusabili- 
ty of your objects. 
And reusability is 
what BOP is all 
about. 

Taking another 
cue from real life, 
the solution to 
problems generat- 
ed by stereotyped 
behavior is intelli- 
gence — some 
sort of AI. An 
object has to be 
able to learn its 
new environ- 
ment, to adapt to become as efficient 
as possible there, and to store all that 
data separately from its basic behavior 
data, so that it won't necessarily apply 
it to other environments. 



BrainBOP Overload 

i OP, as it exists now, is not meant 
* for dummies. It excels when the 
task is to build something simple using 
a few prebuilt objects and some of the 
more straightforward modifiers. But as 
soon as your project has reached any 
level of complexity, it can become a 
major brain-stretcher. As mentioned 
earlier, you're no longer looking at 
things from one point of view. You're 
forced to see things from the perspec- 
tive of each of your objects and then 
imagine how all of them will relate to 
each other. 

mFactory is working hard on their 
debugging tools. Progress with naming 
conventions will also help. In the mean- 
time, mTropolis is not scriptor-proof. 

Is mTropolis a tool for nonprogram- 
mers, such as animators, writers, and 
others? The fact is, there are plenty of 
artists using the tool right now, quite 
successfully. Not having to memorize a 
set of commands and syntax helps. 
Most of the learning curve is just in 
twisting your head around to think in 
new ways. Nevertheless, it helps to 
have a code hacker around to create 
extensions when you need them, or to 
deal with the mathematics and algo- 
rithm matters. 



■ 



FIGURE 4 . The Behavior Window for the motion logic of 
the rocket. By selecting the Coast message track, any modi- 
fiers associated with that message are easily distinguished. 



For generating good ideas and trying 
out new behaviors and interdynamics of 
elements from past projects, nothing 
beats mTropolis. But beware, your pro- 
ject will be molded by mTropolis's limi- 
tations and demands, as any good pro- 
grammer always falls for the most 
elegant solutions within whatever envi- 
ronment he's working. 

If you're new to the game develop- 
ment scene and don't yet have an 
engine all your own, mTropolis may be 
the place to start. If you have an engine 
that you're satisfied with already, you 
might consider fusing it with 
mTropolis using MOM. Or just use 
mTropolis as a prototyping tool. ■ 



mFactory /Quark 

Burlingame, Calif. 

650-548-0600 

www.mFactory.com 
Price: $995 estimated street price for 

version 1.1. Free upgrade to version 

2.0 for new 1.1 purchasers. 
Systems Requirements: The minimum 

configuration recommended for 

authoring in mTropolis is a 68040 or 

Power Macintosh with 

• 6MB RAM (for 8-bit color) or 8MB 
RAM (for 24-bit color) 

• System 7.x 

• QuickTime 2.5 

• Sound Manager 3.2 

The minimum configuration recom- 
mended for playback is a 68030/ 
68040/Power Macintosh or 
486/Pentium PC with Windows 
3.1/95/NTand 2MB RAM. 



http://www.gdmag.com 



MARCH 1 998 GAME DEVELOPER 



Bock. 






PROG R A M M 1 N C 


TUTORIAL 



Peeki g 

Th gh P al 

btf Adrian Peres 




n the few eons of cyber-time since BattleZone, it seems that com- 
puters have finally become fast enough to handle complex 3D 
geometry that approaches what we see in the real world. Every new 
Quake/Duke/Tomb Raider engine seems to have more and more 
polygons in an average scene. Rasterization speed in particular has 
gone through the roof in the last few years. With installed 3D accel- 
erator cards in the millions and many computers this past holiday 



season shipping with them pre- 
installed, a high fill rate doesn't seem 
to be as much of a pressing problem 
today. Many developers are likely 
breathing a sigh of relief — at least 
those who hate trying to squeeze cycles 
out by tweaking assembly routines. 

However, a perfect world does not a 
high fill rate make. As worlds become 
more complex and game players kick 
and scream for more features, a much 
bigger problem is beginning to arise: 
hidden-surface removal. Effectively 
managing large data sets of polygons, 
culling the polygons that are complete- 
ly out of view, clipping the polygons 
that are partially out of view, and 
drawing the polygons that are in view 



is no simple task. Also, while game 
developers generally agree on the 
"best" way to draw texture-mapped or 
Gourad-shaded triangles, hidden-sur- 
face removal is still an area of great 
research. There really is no best way to 
do it, only a number of different tech- 
niques that have their own strengths 
and weaknesses. 

Binary space partition trees (BSPs), 
which have been used in game devel- 
opment with increasing frequency late- 
ly, have a lot to offer. For the sake of 
discussion, a BSP tree is a binary tree 
that divides an n-dimensional space at 
each node with an (n-l)-dimensional 
hyperplane until the world is divided 
into a set of convex subspaces (at 



Adrian Perez attends Carnegie Mellon University, majoring in Computer Science with 
a focus on graphics and artificial intelligence and a minor in Mathematics. He is cur- 
rently working in his spare time on a hybrid BSP/portal engine he calls Zeta. You can 
contact him via email at amperez+@andrew. cmu.edu. 



which point they can no longer be 
divided). Most importantly, BSPs give 
you a perfectly sorted order from front 
to back or back to front of any scene 
with an astonishingly O(n). This 
means that as the number of polygons 
(n) increases, the processing time (rep- 
resented with an O) increases linearly 
with n. Straight polygon sorting, on 
the other hand, is represented as 0(n 2 ), 
meaning that this method gets much 
slower as the polygon count increases. 
The drawback to this technique is a 
one-time, relatively time-consuming 
BSP tree-building phase. BSP trees are a 
complex and abstract topic in and of 
themselves. A more complete descrip- 
tion than I could include here can be 
found in Computer Graphics: Principles 
and Practice by Foley, van Dam, et al. 
(Addison Wesley, 1996). 

However, BSPs are not a cure-all. 
Constructing a BSP tree is time con- 
suming, so much so that it can only 
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FIGURE 2 . Portal rendering techniques allow you to draw only 
pixels that are visible from the camera's viewpoint. 




FIGURE 1 . Sliding doors in Doom is one way 
of working around the restrictions associated 
with a static data set. 



realistically be done before executing 
the game, which completely restricts 
you from modifying the data set in any 
way apart from limited workarounds 
(such as the doors that slide up and 
down in Doom, shown in Figure 1). 
Static worlds are fine, but eventually 
they'll cramp designers, and players 
will demand more. Also, BSPs don't 
have occlusion built in (I think that 
they do support this feature, but the 
important thing is that nobody knows 
how to do it yet). 

For example, imagine you're drawing 
the inside of a house. You generally 
won't be able to see any polygons 
upstairs from any point downstairs 
besides the stairwell. However BSPs 
cannot cull those upstairs polygons 
automatically. Doom got around this 
by having a front-to-back buffer — 
every scanline was drawn once and 
only once, and it traversed back until 
nothing else could be drawn. Although 
amazingly effective, this method trans- 
lates very poorly to 3D. Edge sorting 
took care of the overdraw in Quake, 
but no edge sorter in the world can 
handle all the polygons for every frame 
of a typical 3D world at any reasonable 
speed. So id incorporated a potentially 
visible set (PVS), where the visibility at 
each node is precomputed and stored, 
so at run time only a small list of nodes 
needs to be processed. In practice, the 
PVS is not a BSP technique. It's really a 
concept belonging to portal rendering. 



Portal Rendering 




Portal rendering is an alternate 
way to treat 3D scenes. It's been 
around since 1971 and has been (or 
will be) used in games such as 



Descent, Duke 
Nukem 3d, 
Unreal, and 
Prey. It operates 
under a surpris- 
ingly simple premise: if I'm drawing 
two rooms that are connected through 
a doorway, after drawing the room 
that I'm currently in, the only part of 
the screen that hasn't been drawn yet 
is the area that can be seen through 
the doorway; if I restrict the drawing 
space to the dimensions of the door- 
way, I'll only draw those pixels of the 
next room that I can actually see, giv- 
ing me zero overdraw (Figure 2). The 
world is represented as a collection of 
convex hulls, connected with poly- 
gons that are tagged as portals. Convex 
hulls are collections of polygons that 
have no concavities. You can draw a 
line from any point inside the hull to 
any other point inside the hull and, by 
definition, that line will never leave 
the dimensions of the hull. Cubes, for 
example, are convex hulls that can be 
considerably deformed before they 
become concave (Descent used a con- 
nected cube scheme to accelerate por- 
tal rendering). To draw a scene, you 
start with a base portal with the 
dimensions of the screen (or the area 
that you're drawing) and draw the cur- 
rent hull you are in. Every time you 
encounter a polygon that's tagged as a 
portal, you recurse into the next cell, 
clipping the new portal against the 
current portal until you cannot see 
any new portals. 

Portals work remarkably well when 
the conditions are right. The Build 
engine (used in Duke Nukem 3D, 
Redneck Rampage, Blood, Shadow 
Warrior, and others), for example, 
uses 2D portals to a great effect. Instead 



of having a front-to-back buffer as 
Doom has, Build games draw convex 
sectors, clipping the scene to portals as 
it recurses backwards. The Build engine 
achieves moving sectors by performing 
virtually no precalculation on the 
scene. It is thus dynamic: doors can 
swing out, gears can spin around, and 
walls can explode. In addition, as a 
pure portal system, the Build engine 
allows floors above floors, another 
effect that wasn't possible in a straight 
BSP system such as Doom. 

Descent uses portals to reduce over- 
draw to zero and to accelerate culling 
(Figure 3). A Descent level is a collec- 
tion of convex six-sided polytopes (3D 
polygonal objects). Each polytope is 
connected on each side with, at most, 
one other polytope. To draw the scene, 
you simply recurse and clip the portals 
to each other as you step down the list 
of cubes. Both Doom and Descent run 
on fairly low-end machines, yet feature 
an amazing amount of eye-candy for 
the horsepower. 



- % 



FIGURE 3. Descent uses portals to 
reduce overdraw to zero and to accel- 
erate culling 
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FIGURE 4 . Each portal creates a new set of clip- 
ping planes based on the camera location and the 
locations of the portals vertices. 



clipping planes 




Implementing Portal Rendering 

To implement a portal-based 
engine, you have several options. 
The most fundamental design decision 
is whether you want to use 3D clipping 
or 2D clipping, each of which has its 
advantages and disadvantages. 2D clip- 
ping is typically done on a per-scanline 
basis, and since most triangle raster 
code has built-in clipping support, this 
isn't a very tall order to fill. 

Start drawing your image with a 
table of extents, so that each scanline 
has a start, end, and active field. As you 
reach portals, modify the table, clip- 
ping each scanline and calculating the 
new extents to determine if the current 
scanline is covered by the polygon. At 
this point, drawing the polygon is sim- 



FIGURE 6. An overhead view of 
which polygons are drawn and which 
are culled in this article's sample 
application. 



ply a matter of drawing 
only the active scanlines 
and only the appropriate 
pixels in those scanlines. 

The good news about 
this method is that draw- 
ing polygons requires only 
a few lines of logic code 
within the function, as 
well as a couple of if state- 
ments in the code for each 
scanline. The bad news is 
that this method trans- 
lates very poorly to 3D 
hardware, which generally 
draws a triangle at a time, 
rather than scanlines. 
Also, although a few extra 
if comparisons may not 
seem like much, they tend 
to stack up when you're 
rendering at 640x480 reso- 
lution and clipping in three dimen- 
sions rather than two — especially 
when you're drawing large sets of 
polygons. In practice, portal rendering 
using 3D clipping may be faster, espe- 
cially as resolution, portal count, and 
polygon count increase. 

When implenting 3D clipping, start 
with a clip volume that consists of the 
area visible on the screen. When you 
encounter a portal, clip the polygon 
to the 3D volume and create a new set 
of planes based on the two vertices of 
each edge and the camera location 
(Figure 4). The good news is that this 
isn't much more computationally 
demanding than traditional 3D clip- 
ping, although it requires a little more 
time to generate the new frustums. 
The problem with this method is that 
you're clipping more often, and thus, 
you have to perform a few 
sqrtsO to normalize the new 
planes when you clip them to 
the portal and generate the new 
frustum. Each sqrtsO requires 
about 100 cycles each — not too 
good for performance. 

This is the method that the 
included engine (available on 
the Game Developer web site) 
uses. The file it loads has poly- 
gon information for all eight 
cells (four rooms and four door- 
ways), and all polygons have an 
ID tag. This tag is -1 for nonpor- 
tal polygons (the walls, the ceil- 
ings, and the floors). For the 
clear portal polygons that repre- 




FIGURE 5 . A view of the Device 
Independent Bitmap from the engine 
that accompanies this article. 



sent the doorways, the tag contains an 
index into an array, indicating which 
cell in the data set lies on the other 
side of the portal. 

Here's how it works. At each frame, 
the camera is moved according to user 
input. The camera is bounds-checked 
to make sure it's in a cell and the index 
of the cell is noted. Then a new frus- 
tum is generated. Finally, a single call 
is made to draw the current cell with 
the current frustum. The function 
automatically clips the frustum to any 
portals and recurses as needed. It draws 
the view into a Device Independent 
Bitmap (DIB) and then blits to the 
screen (Figure 5). 

It's important to note that the initial 
clip volume only has four planes. A far 
clip plane is unnecessary because draw- 
ing will stop before any appreciable 
distance. A near clipping plane is not 
recommended when using this render- 
ing method, because as you get very 
near a doorway, the portal itself 
becomes clipped and the next room is 




FIGURE 7. The Quake engine does not imple- 
ment portal rendering because each level 
contains a prohibitive number of portals. 
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not drawn until you enter it. When I 
created the engine that accompanies 
this article, I kept it restricted to flat 
shading and didn't use any lighting or 
mirrors, which cut down the code com- 
plexity. There is also an overhead view 
(Figure 6) so you can see the polygons 
being dynamically clipped as the cam- 
era moves around. 



The Drawback of Using Portals 

Just as BSPs (and, in fact, as any hid- 
den-surface removal algorithm), 
portal rendering has its faults. Clipping 
portals is not a computationally simple 
thing to do, and in most portal render- 
ing systems, it ends up being the limit- 
ing factor. This is why, for example, 
Descent slows down considerably in 
large, complex rooms: the clipping of 
literally hundreds of portals bogs down 
the game. John Carmack once told me 
that he had tried implementing portal 
rendering in the Quake engine, but 
found the overhead from clipping por- 
tals to be prohibitive. He said that in a 
typical Quake level, there would be lit- 
erally twice as many portals as poly- 
gons (Figure 7) — the geometry alone 
would kill you. 



Implementing Good Portal Effects 

However, portals are not without 
their perks. You can achieve an 
amazing amount of special effects with 
portals, effects that are difficult (if not 
impossible) with other hidden-surface 
removal methods. 

Lighting. Real-time shadows are always 
difficult to accomplish in 3D graphics, 
but portal rendering offers a very ele- 
gant way to do it. For every light in the 
scene in your general area, perform a 
portal render using the light as the vir- 
tual camera location and its spotlight 
as the initial frustum. When that's 
done, you have a set of polygons visi- 
ble from the light. Tag those polygons 
that were trivially accepted as lighted 
and those that were trivially rejected as 
unlighted. Make note of any split poly- 
gons and store this split information in 
the global polygon list (perhaps using 
pointers in the polygon structure to a 
temporary polygon pool that stores the 
lighted/unlighted members of split 
polygons). Perform these actions for 



every light. Then, when the scene is 
drawn, you proceed as normal, using 
the lighted/unlighted/split information 
for drawing. When a conservative 
number of lights is used in a full-portal 
environment, you can implement 
moving, turning spotlights that light 
the scene in real-time. 
Mirrors. A real-time mirror is another 
feature with which portals can help. 
Some portals can be tagged as mirrors, 
which means that instead of recursing 
into the cell on the opposite side, we 
recurse again into the original cell, 



using mirrored camera and frustum 
information. To mirror the camera, use 
a dot product of the camera location 
and the plane's normal to find the dis- 
tance from the camera to the origin 
(Figure 8). You subtract from this the 
distance between the plane and the ori- 
gin, which gives you the distance from 
the camera to the plane. Then double 
this value (to get the distance from the 
camera to a point on the opposite side 
of the plane that is the same distance 
from it), multiply it by the normal (giv- 
ing you a vector that goes from the cam- 



FIGURE 8 . To mirror the camera, use a dot product of the camera location and 
the plane's normal to find the distance from the camera to the origin. 
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FIGURE 9 . To reflect the camera axis, treat the plane normal and all normals of 
the axis as if they were coming out of the origin. 
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era to the reflected camera), and add the 
displacement to the camera vector. 

To reflect the camera axis, you use a 
similar procedure. The most notable 
difference is that you treat the plane 
normal and all normals of the axis as if 
they were coming out of the origin 
(Figure 9). You find the distance from 
each vector to the plane, double it, 
multiply it by the plane normal, and 
displace it. Caution must be used here, 
especially when two mirrors can see 
each other, as an infinite loop can 
occur. One way to deal with this with- 
out losing much visual accuracy is to 
treat the mirrors as imperfect, slightly 
darkening the image on each reflection 
and ending recursion after enough 
reflections make whatever you draw 
black. You can reflect lights off of mir- 
rors with the same approach, creating 
some incredible special effects. 



Displacing Portals 

You can displace portals using 
many of the same ideas that I've 
discussed with regard to reflecting por- 
tals. Instead of just reflecting the cam- 
era about a certain plane, you move it 



to a completely new location. You can 
try this for yourself in Duke Nukem 3D. 
Bring up the automap, zoom all the 
way out, and then jump into some 
water. YouTl see yourself jump to a dif- 
ferent corner of the map as soon as 
you enter the water. Portals such as 
this can be used for closed circuit TV 
displays, for quickly jumping to differ- 
ent areas of the map, or for an eerie 
floating doorway that leads into a 
completely different room. If the 
source and destination portals are par- 
allel, you can simply displace the cam- 
era by their difference when you tra- 
verse the portal in the drawing 
sequence. Nonparallel portals are a bit 
trickier, requiring more matrix math 
than I have space to discuss. 

A lot of buzz is in the air regarding 
half-portal techniques. Quake 2, for 
example, uses what John Carmack 
calls "area portals" to help with hid- 
den-surface removal. In this tech- 
nique, levels are sectioned off into 
areas connected by doors, and the 
parts on the other side of closed doors 
are not considered by the engine for 
drawing. As soon as the door opens, a 
flag is raised, signaling that the far 
area is drawable. 



Learn Something New 

hether you're programming 
games, Internet security sys- 
tems, or ugly scientific visualization 
programs, you should focus on good 
(meaning abstract and hard to visual- 
ize) algorithms. There's no "right" way 
to do anything, merely a bunch of 
good ways (and a whole lot more bad 
ways). As the programmer, it's your 
responsibility to look at what you want 
to accomplish and to choose the best 
algorithm to reach your goal. To do 
this, you need to know about as many 
algorithms as possible, including their 
strengths and weaknesses. You need to 
be able to maximize the good and min- 
imize the bad by tinkering with these 
algorithms. Portal rendering has a lot 
of very good points and a lot of not so 
good points, and it deserves considera- 
tion when you're analyzing possible 
hidden-surface removal techniques. ■ 



Visibility Computations in Densely 
Occluded Polyhedral Environments by 

Seth Jared Teller, University of 
California at Berkeley. Available at 
http://sunsite.berkeley.edu/NCSTRL/ 

Database and Display Algorithms for 
Interactive Visualization of Architectural 

Models by Thomas Funkhouser, Univer- 
sity of California at Berkeley. Available 
at http://sunsite.berkeley.edu/ 
NCSTRL/ 

3D Engines List. Available at 
http://cg.cs.tu-berlin.de/~ki/ 
engines.html. The list has information 
on many types of 3D engines (includ- 
ing mine). Some of these are based on 
portals. 

Homepage of Jacco Bikker (aka The 
Phantom) at 

http://www.geocities.com/Cape- 
Canaveral/5402/index.htm. This page 
has the source code to a scanline-clip- 
ping portal rendering engine and some 
information on how he built it. 

Homepage of Nark Feldman at 

http://www.geocities.com/Silicon- 
Valley/2151/. This is the home of the 
in-development Win95GPE, which has 
documentation about (among other 
things) portal rendering, DIB program- 
ming, and Direct3D 5 Immediate Mode. 
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ecause many of us game artists will see more of 3D 



Studio MAX 2 in 1998 than we will see of our 



spouses, we'd better take a really hard look at 



the upgrade before we commit. As with any- 



thing else on which we spend lots of time and 
money, we need fair, honest opinions that are 



closely based on first-hand experience. My own 



work focuses on low-polygon, real-time 
3D modeling and animation, not pre- 
rendered work. For example, we RT3D 
artists deliver to our clients 3D models 
(such as VRML .WRL files), not .AVIs. 
So new rendering effects such as lens 
flare don't rock my world. I love things 
such as better interfaces, vertex editing 
improvements, and really good 
import/export options. 

Regardless of how you have or will 
use MAX 1, you may wonder if the 
$795 upgrade for MAX 2 is worth it. 
The quick answer is that if MAX is your 
main 3D tool and you're not poor, you 
should buy the new version. This 
upgrade is a big one — the scripting 
language alone will be worth the 



money. And there are plenty of other 
major reasons to upgrade. 

Let's take a look at it: Figure 1 is the 
obligatory screen capture. Compared to 
MAX 1, it hasn't changed that much. 
But despite the similar look, MAX 2 has 
a whole lot of changes, some of them 
very substantial improvements. Many 
small, annoying problems in MAX 1 
have been fixed in MAX 2. Kinetix has 
hyped this point heavily, and the com- 
pany is right to do so. Everywhere you 
turn, existing features are easier to use 
and more powerful. For example, the 
align tool now works on subobjects; 
that means you can align vertices now. 
I'd be curious to know how many bugs 
and features improvements were 
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kills time between soccer games. 



implemented for MAX 2; I bet it's in 
the thousands. For me, these many 
small fixes make up one of the most 
compelling reasons to upgrade. 

Most of the major improvements 
and rebuilds fit into a few general cate- 
gories: modeling; materials, rendering, 
and animation; interface; display 
improvements; documentation and 
support; MAXScript; and miscella- 
neous. For each category, I'll highlight 
a few of my favorite features, discuss 
the ones that I've actually used in 
detail, and list others that I think are 
interesting but didn't actually use. 

Modeling 

One of my favorite improvements is 
MAX 2's more holistic approach 
to editing model vertices, edges, and 
faces. This is big news for real-time 
modelers. Editing vertices in MAX 1 felt 
as if I was tinkering under the hood of 
the model where I didn't belong. I had 
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FIGURE 1. MAX 2 compared to MAX i: evolution not revolution. 



to keep the stack collapsed all the time 
or I'd get spurious problems. MAX 2's 
interface for subobject editing is cleaner 
and easier to use, though I haven't used 
it enough to be reassured that the stack 
problems have been addressed. 

The addition of NURBS modeling is 
the other big news. Many of the MAX 
users that I talked to were very excited 
about this feature. After playing with 
it, I think it's a pretty nifty improve- 
ment as well. You can update the 
NURBS surface in real time, watching 
the surface change on the screen as you 
move a control point or curve. 
Unfortunately, you can't create holes 
in a NURBS surface, and I found parts 
of the interface clunky (Figure 2). 

The manuals have some good back- 
ground on NURBS modeling, but con- 
spicuously lack any detailed how-to 
information for basic NURBS proce- 
dures in MAX. I didn't see any printed 
tutorials on NURBS either. Regardless, I 
stumbled through the procedure, and 
once I had a NURBS object on the 
screen, things got easier. I especially 
like the Refine tool: as you move the 
icon toward the control lattice, new 
vertices magically appear, just where 
you hoped they would. At least, that's 
how it happened for me when I played 
with it; I have yet to build anything 
really complicated with NURBS. 

I also like the new Preserve modifier, 
which constrains a mesh to a certain 
volume. It can also constrain the curva- 
ture of a surface by enforcing minimum 
angles between face normals (in much 
the same way that Autoedge does). 

Shape modeling has several excellent 
improvements, including Slice, which 
generates a planar cross-section shape 
of any 3D object. This is really handy 
for merging objects. Normally, I use 
the Boolean with a box to get a cross- 
section, but that's problematic. The 



text shape generator also sports some 
really good improvements, such as 
kerning, multiline text, and so on. 

UV mapping has a handy new fea- 
ture: the Unwrap UVW modifier allows 
you to move the mapping coordinates 
individually in UV space (Figure 3). 
This unwrapping concept is common 
in 3D paint programs, but it's nice to 
have it integrated into MAX 2. The 
interface is simple: you "unwrap" the 
mesh onto the texture, then just move 
the points around and watch the tex- 
ture mapping update on the 3D object. 
UnWrap UVW lets you fix mapping 
that needs to be carefully aligned to 
the underlying mesh — an eyebrow, 
for example. I had some difficulty 
selecting coincident-mapped vertices, 
such as the vertices at the top of the 
cylinder shown in Figure 3. I'd like to 
be able to select 3D vertices along with 
the vertices on the unwrapped texture. 



Materials, Rendering, and Animation 

The materials editor got a fairly 
major rebuild in 
MAX 2. Many new 
features abound. One 
feature that I think is 
great for prerendered 
work is cropping — 
the ability to use part 
of a larger bitmap as 
a texture. For exam- 
ple, if you have an 
image with stripes on 
one half, you can 
define a region in the 
striped area and 
assign only that 
region as a texture. 
Previously, of course, 
you had to create a 
separate bitmap. 



Cropping is useful for a technique 
that I call texture clumping: grouping 
textures into sizes and shapes that are 
friendly to real-time graphics engines. 
Many graphics cards and rendering 
engines require square textures that are 
8, 16, 32, 64, 128, 256, or 512 pixels on 
a side. This is an annoyance for RT3D 
artists. We're always trying to squish 
nonsquare textures onto square sur- 
faces, no simple matter when you have 
a long, thin texture. One approach is to 
"clump" several long, thin textures 
into a single image, then use clever 
mapping to get a particular part of the 
texture onto the model. 

At first, I thought that was the pur- 
pose of the cropping feature in MAX 2 
— but it isn't. The UVs on the mapped 
object aren't modified when you change 
the cropping settings in the material edi- 
tor (or at least the UVs that are exported 
in the VRML output aren't modified). 
I'm guessing it saves a "transform" for 
UV coordinates on that material. That 
works fine for prerendered work, but it's 
ignored when MAX 2 exports VRML. 

A lot of the work that was done to 
develop good rendering tools for the 
original release on MAX 1 was carried 
through to its next logical step in MAX 
2. Some of it worked well, some not so 
well. For instance, MAX 2 offers space 
for more rendering sample windows — 
up to 24, with lots more options includ- 
ing custom background and object 
selection. Raytraced reflections and 
refractions are here — a welcome addi- 
tion to this release. MAX 2 allows selec- 
tive ray tracing (per-object), which 
could really save time. MAX's particle 
systems improved a lot. Users can now 




FIGURE 2. The elusive modeless NURBS dialog. 
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use arbitrary objects for the particle, 
including meta-particles — blobby par- 
ticles for flow simulations. Particles also 
behave according to the new physics 
system, bouncing off surfaces and so 
on. There's support for Photoshop and 
Premier filters, which is kind of a no- 
brainer, but you have to appreciate the 
inclusion anyway. The new Blinn ren- 
dering looked a pretty nice, but it 
wasn't revolutionary. Blinn rendering is 
variation on Phong. As with Metal ren- 
dering in 3D Studio 4, Blinn is another 
scan-line rendering variation. 

Since I'm not an animator per se, I'll 
just give a quick summary of the new 
animation features that sound most 
interesting. Subobject animation lets 
you animate vertices, faces, and edges. 
Additionally, the built-in Bones system 
looks easy to use and straightforward. 
MAX 2 supports motion capture data, 
including real-time motion input and 
key reduction. It's interesting that sup- 
port for motion capture is part of MAX 
2; Character Studio 2.0 (demonstrated 
at SIGGRAPH '97) is supposed to offer 
some very similar features. MAX 2 also 
offers dynamic simulations, including 
basic physics features such as fall, slide, 
collide, and bounce. 

Character Studio 1.2 for MAX 2 is 
included on the CD with MAX 2, but it 
won't fully install unless you already 
own the previous version. The features 
are basically the same; as with any 
other plug-in, Kinetix updated it so it 
would work with MAX 2. 



Interface 

I think MAX 2's weakest point is its 
user interface (UI). On the plus side, 
it's easy to learn and several of the 
underlying ideas (good use of context 
menus and some 3D interface innova- 
tions) help make work easier. 

That's about all the good points that 
occur to me. On the negative side, 
MAX 2's UI is inconsistent and inflexi- 
ble. The mouse-only approach is slow 
and error-prone, which would be for- 
givable if I could just edit the toolbar 
and access everything with keyboard 
shortcuts, as I can with Microsoft 
Office applications. Alas, MAX's UI is 
about as flexible as the immutable 
forces of nature. That's bad in any 
application and unforgivable for a 
product that leads an industry. 



FIGURE 3. Unwrapped UVs. 



What's inflexible 
about MAX's UI? 
One of my biggest 
complaints is that 
the input is depen- 
dent on mouse 
movement, and the 
keyboard shortcuts 
are substandard. The 
list of key-assignable 
commands is frustrat- 
ing: it's unorganized 
and lacks many 
major commands. 
For example, there's 
no way to assign a 
keyboard shortcut to 
the commonly used 
editing command 

Move Vertex. Moving a vertex requires a 
varied sequence of precise mouse clicks. 

Unlike most modern software, MAX 2 
doesn't allow the user to customize the 
screen layout. Modeless dialogs are not 
resizable, the menu structure is frozen, 
and Kinetix's sidebar is certainly not 
customizable. The user is stuck with 
Kinetix's idea of perfection (prominent- 
ly featuring the Percent Snap button) for 
all eternity. Furthermore, MAX doesn't 
have the standard Window main menu 
item; it was combined with the View 
menu, so opening the Materials Editor 
window is under the View menu. Also, 
don't change your screen color to a 
black background: MAX's material selec- 
tion font is always black. 

Again, most of those layout issues 
wouldn't be worth mentioning if 
MAX allowed the user to change them 
— but it doesn't. Heck, I'm even 
annoyed at $25 shareware that doesn't 
allow me to drag and drop toolbar 
buttons; when my $2,500 software 
package doesn't have a customizable 
UI, I'm horrified. It especially burns 
me because Kinetix obviously spent so 
much time and energy on MAX 2; 
how could it ignore the UI? 

Other UI problems are abundant, 
though less critical. White space is 
poorly used. Some of the side-bar but- 
tons resemble Windows 3.1 dialogs: 
huge fonts with poorly designed white 
space. Some of the most confusing 
dialogs (for example, the snap setup) 
are much improved, but the interfaces 
to newly introduced features are not. 
For example, the modeless NURBS 
floater window (which is begging to be 
a docking toolbar) consumes my pre- 




cious desktop with useless white space, 
and I can't resize it. 

Nonfiling 3D windows would have 
been nice. According to Kinetix docu- 
ments, the display tiles for perfor- 
mance reasons. Why not let users 
decide that trade-off? Some of us have 
darned fast computers; we'd rather 
have our interface flexible than fast. 

And then there's Strokes, a move- 
ment-recognition system that reminds 
me of the Apple Newton's handwriting- 
recognition system: cute and innova- 
tive, but poorly implemented. I found 
that it worked for the preset functions, 
but adding new functions wasn't practi- 
cal. The UI didn't let me edit the stroke 
shape, and its recognition was very 
primitive. My initial impression was 
that it's a pure gimmick, but when I 
realized Strokes could assign keyboard 
shortcuts, I got all excited: "Strokes be 
damned, if this thing lets me set key- 
board shortcuts to anything, then it's 
great!" Nope. It offers the same crippled 
list of assignable functions as the stan- 
dard MAX interface, with a only a few 
others thrown in. Sigh. 

In a few cases, Kinetix has some 
good, forward-thinking interface 
designs in MAX 2, especially in the 3D 
interface area. Most notably, the snap is 
now predicted by a light blue 3D cur- 
sor, underneath the 2D cursor and 
showing where the grid (or endpoint, 
or whatever) is. This works far better 
than MAX 1, although it's a little slug- 
gish and sticky-feeling (even on my P2- 
266). Another nice 3D interface is the 
highlighting of available edges on 
NURBS surfaces — as with the snap, the 
appropriate 3D object lights up as you 
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FIGURE 4. MAX 2's Edged Faces view. 



pass the cursor over it, a quick, intuitive 
interface that works really well. 

Kinetix can afford to be playful with 
its 3D interface since there aren't many 
decent precedents. However, if Kinetix 
wants to replace standard features such 
as docking toolbars, the solution has to 
improve upon the original (as in unclut- 
tered, flexible, fast, and intuitive). 

Display Improvements 

I love the new Edged Faces view 
(Figure 4). It's a combination of wire- 
frame view and smooth plus highlight 
view, and it probably took Kinetix 
about 10 seconds to implement (not 
that we users care). Real-time 3D mod- 
elers especially appreciate this one: we 
often need to see face boundaries while 
working with textured surfaces. To 
work around this problem in MAX 1.2, 
my coworker Lisa Washburn realized 
that the poor lighting in MAX's ren- 
dered views could be a feature, not a 
bug. She put a bright light in the scene 
and viewed the model in facet plus 
highlight mode, which textures the 
model with simple lighting. The severe 
lighting changes at the face boundaries 
revealed the edges of the faces. Of 
course, this workaround has drawbacks: 
not all edges are always visible and it's 
difficult to see the original texture. 

One of MAX 2's most touted features 
is its direct support for OpenGL and 
Direct3D. Apparently, Kinetix decided 
that Heidi needed alternatives — under- 
standable, given such stiff competition. 
I hope it works for others, but I didn't 
have much luck in my own test. I'm 



using STB's Velocity 
128 AGP graphics 
card in my P2-266 
workstation, and I 
couldn't get MAX 2 
to make use of it. 
Neither the Direct3D 
nor the OpenGL 
options worked. 

I embarked upon a 
little journey 
through Kinetix's 
tech support and 
documentation. In 
summary, I found 
the following: 
Kinetix has a web 
page that lists com- 
patible cards 
(www.ktx.com/3dsmaxr2/html/graph- 
ics_cards.html), but as of this writing, 
there wasn't much on there — they 
didn't test the Rendition Verite, for 
example, which is one of the most 
common hardware accelerators avail- 
able. Somebody in tech support told 
me that MAX 2 requires 8MB of video 
RAM for Direct3D support (I'm not 
sure that's true). Furthermore, I learned 
that the Direct3D support requires the 
DirectX 5 drivers — often, manufactur- 
ers are shipping DirectX 5 with DirectX 
3 drivers. For OpenGL support, I need- 
ed to get drivers for version 1.1 or later 
from the card manufacturer (STB 
doesn't have any OpenGL drivers on 
their site). After some checking, 
Kinetix's tech support told me that 
using OpenGL under Windows 95 is 
"not possible," but that he'd check into 
it further and get back to me. 

At a local users' group meeting, I 
learned that several people had success- 
fully set up MAX with OpenGL and var- 
ious graphics cards. One user reported 
that the Permedia with the OpenGL dri- 
ver distorted textures, but that the 
problem disappeared when the software 
driver was used. Another user reported 
that the TrueFX Pro card also had dis- 
tortion with OpenGL. Others reported 
that oddly enough, hardware accelera- 
tion didn't make that much difference 
to display performance; in one case, the 
software Z-buffer was 30 percent faster 
than the hardware-accelerated OpenGL 
driver. However, because OpenGL can 
easily be set up to bypass the hardware, 
I think it's possible that this report is 
inaccurate. No one else at the meeting 
had used MAX with a Riva 128-based 



card, so I didn't get any insights into 
my own hardware woes — and my card 
still won't accelerate MAX. 

Regardless of hardware acceleration, 
some of my fellow artists report that 
MAX 2 has improved their display per- 
formance significantly. I tested this by 
creating a simple benchmark test: about 
ninety simple wireframe screen redraws 
and view transforms. Here's what I did: 

1. Start MAX clean and make sure it's 
maximized. Create a Sphere object 
(16 segments), apply an edit mesh 
modifier, and Go to Sub-object/Face. 

2. Change to the front view. Zoom 
extents, and make sure it's a wire- 
frame view, with no grid showing 
and degradation override enabled. 
Select a face on the equator that has 
the right edge aligned with the axis 
of the sphere. 

3. Choose Arc Rotate, click on the 
sphere, and start timing as we hold 
down the right arrow key. When all 
the red edges of the selected face 
have rotated so that they're all invisi- 
ble, measure the elapsed time. 

After entering my ultra-clean-secure- 
turbo test environment (a clean boot of 
my usual computer), I ran the test on 
the slowest MAX-capable machine I 
have: a Compaq Armada 4130t laptop 
(P133, 48MB RAM, 800x600x16 display, 
and built-in graphics) running Windows 
95. Of course, with this low-end hard- 
ware, both MAX 1 and MAX 2 can only 
use their basic software display drivers. 



TABLE 1. Wireframe 16-Segment 
Test Results. 



Software 

MAX 1.2 
MAX 2.0 



Time 

35 seconds 
30 seconds 



TABLE 2 . Wireframe 256-Segment 
Test Results. 



Software 

MAX 1.2 
MAX 2.0 



Time 

73 seconds 
60 seconds 



TABLE 3. Texture plus Highlight 16- 
Segment Test Results. 



Software 

MAX 1.2 
MAX 2.0 



Time 

35 seconds 
31 seconds 
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Table 1 shows the results of the initial 
test. As you can see, MAX 2 was a little 
faster than MAX 1 (17 percent improve- 
ment). The test seemed to reflect my 
experience in using MAX 2 (that is, a 
small performance difference). But it 
made me curious: Was there a big per- 
formance increase with geometry han- 
dling, while my little test only looked at 
screen redraws? I reran the test with a 
great big 256-segment sphere. This 
monster had thousands of faces in the 
same screen area as the other sphere. 

Table 2 shows the test results for the 
256-segment sphere. The 22 percent 
improvement shown in this test made 
me think that MAX 2 has improved 
more in geometry handling than it has 
in its software-rendering pipeline. But 
what about nonwireframe objects? For 
this test, I created a sphere with a 
default material and added a bitmap 
("sunset90.jpg") to it. I deleted a face 
for reference and applied mapping as 
well. The results are in Table 3 and, 
again, show a small performance 
improvement (13 percent, roughly). 

I can almost hear the developers who 
sweated out those 10-20 percent perfor- 
mance increases grinding their teeth 
when I call them "small improve- 
ments." Let me explain: while I 
applaud any performance improve- 
ments, they don't really change the 
way I work with MAX — especially 
since I can get a cheap hardware card 
and get a 100 percent or better 
improvement in performance. If I had 
the choice, I'd prefer improvements in 
accuracy, not speed. MAX 2 still has 
those really nasty interpenetrating 
object borders in smooth plus high- 
light Z-buffering, for example. 



Documentation and Support 

Fortunately, the problems that I 
encountered trying to get my cheap 
graphics card to accelerate MAX gave me 
an opportunity to test Kinetix's support 
system. First, I started where all good 
users start: the manuals. When it comes 
to Direct3D and OpenGL support, I 
found a very terse, single-page discus- 
sion hidden in the back of the manual 
and one paragraph about OpenGL on a 
loose card in the box — that was it as far 
as printed documentation. 

The online help is all new, and it's 
based on Microsoft's Internet Explorer 



instead of the standard Windows help 
system. I couldn't see what advantages 
it offered over normal help: It was dif- 
ferent, but not clearly better. For exam- 
ple, it lacks the "«" and "»" buttons 
that I like for browsing neighboring 
topics. It has slick features such as 
smooth scrolling rather than snap- 
jumps when you push the [Page Down] 
key, and the simultaneous index/win- 
dow interface was both good (conve- 
nient to have the topics always pre- 
sent) and bad (on a low-resolution 
screen, I'd prefer to see more text than 
half a window). In any case, the built- 
in help files had more information 
than the printed documentation, but 
didn't help with my driver issues. 

The problem with the documenta- 
tion isn't simply that my particular 
issue isn't adequately covered. Other 
users have complained strongly about 
MAX 2's documentation, saying that 
the manuals aren't as thorough as they 
once were. I agree — MAXScript, for 
example, has almost no printed docu- 
mentation, and help with NURBS is 
difficult to find. Also, the online help 
files are not fully integrated — some 
are in the old Windows help system 
and some are in the new Internet 
Explorer-based system. I couldn't find 
any reason for the discrepancy. 

Next, I spent an hour or two brows- 
ing Kinetix's online support site (sup- 
port.ktx.com). I am so thankful that 
Kinetix online support has finally 
moved off of CompuServe (which I 
find difficult to use, expensive, and 
generally outdated) and onto the free, 
easy-to-access Web. 

The Kinetix support JH^^^^^^H 
site is a sophisticated 
bulletin board sys- 
tem that is fairly 
easy and compre- 
hensive, but you'll 
spend a lot of time 
waiting for pages to 
load. 

Kinetix's support 
site has one unusual 
feature: not much 
privacy. The system 
publishes the num- 
ber of times you log 
in and how many 
posts you've made. I 
didn't mind it per- 
sonally, but it defi- 
nitely felt weird and 



encouraged snooping. ("Is Jane Doe 
working? She's logged on 20 times in 
the last two weeks, with huge long 
posts every time.") Content-wise, 
there's lots of good stuff on there — 
users, both newbies and professionals, 
help other users, and the sysop has a 
very good attitude. Distracted, I 
browsed the MAXScript section, where 
I was very impressed to see John 
Wainwright (the MAXScript program- 
mer) present, chatting amicably with 
the adoring masses. 

Still in pursuit of a solution to my dis- 
play acceleration problem, I browsed all 
the relevant areas that I could find on 
the support site. Surely, other users are 
struggling with the same issue, but I 
found no major answers. 

Still lacking a satisfactory solution 
to my display problem, I called tech 
support. MAX 2 comes with ten days 
of free phone support, which is 
intended mainly for set-up issues, not 
general support. The lines closed 
before 5:30pm, which cost me a day. 
There's 5 l / 2 techs, and they're within 
shouting distance of the QA people. 
The support people say they're very 
active on support.ktx.com — some- 
one's on there every day, answering 
the harder questions (and letting users 
answer each others' easy questions). I 
was very glad to hear that. 

Unfortunately, tech support couldn't 
really answer the question. The person I 
talked to said lots of people are calling 
with the same basic issue: how best to 
use MAX 2 with cheap graphics hard- 
ware. At this point, I'd spent about three 
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FIGURE 5 . MAXScript certainly doesn 't look overwhelm- 
ing... but stand back. 
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hours on this problem and if I wasn't 
writing about it, I would have given up. 
But I have a cheat: Kinetix has special 
people that regularly contact product 
reviewers and offer to help answer ques- 
tions. When my special person contact- 
ed me, I asked her about the difficulties 
I was experiencing with my graphics 
card. She told me that yes, Riva 128 has 
been tested and works via OpenGL. As 
of this writing, that round of communi- 
cation is still in progress, which means I 
still don't know whether or MAX 2 is 
really going to work with this card. 



NAXScript 



AXScript is truly great. That dull 
little button in the Tools menu 
will change the way we use MAX. What 
does it look like? Not much. As Figure 5 
shows, it looks quite pathetic compared 
to today's programming workbenches. 
As an artist, however, I appreciate a 
minimum of confusion when I have to 
confront programming tasks. I wish 
MAXScript included a few more debug- 
ging aids, a better text editor, and better 



help (where are my printed reference 
manuals?), especially for MAX-centric 
commands and actions. Still, the exist- 
ing setup basically works. The example 
code, DEMO. MS, is a nicely written and 
easy-to-understand introduction to 
writing scripts for MAX, but it leaves 
the user wondering where to go next. 

I've done a little noodling around 
with MAXScript. I read the manual and 
wrote a simple function or two. But I 
haven't yet used it enough to evaluate 
its power (or limits thereof). Compared 
to other built-in languages, (I'm experi- 
enced with Word 97's built-in macro 
language, and I spent way too much 
time in AutoLISP, AutoCAD's built-in 
language), I think MAXScript looks 
really good. The syntax is simple, as it 
should be, and many of the annoying 
parts of programming (declaring vari- 
ables and garbage collection, to name 
just a couple) are seamlessly hidden. At 
first, I wasn't impressed by the func- 
tions that interact with specific MAX 
objects in a scene; their names and 
syntax were confusing. 

MAXScript seems quite well integrat- 
ed with MAX. It can interact with 



3D 



Studio MAX-B1 




Rating (out of five stars): OOOO 

Kinetix Inc. 

San Francisco, Calif. 
800-789-4233 
www.ktx.com 

Price (list /street): Full version - $3,495/$2,899; Educational version - $995/$899; 

Upgrade from MAX 1 - $795^695 (commercial to commercial) 
Requirements: At the minimum, you'll need a Pentium 90 with 48MB running Windows 

95. Kinetix recommends a Pentium 166 with 128MB running Windows NT. 
Technical Support: Ten free days from your first call. Other support varies by dealer 

(some will relay tech support issues to and from Kinetix). 
Return Policy: The dealer says there are no returns of any kind allowed. The license 

that comes with MAX 2 says that you can return MAX for a full refund within 15 days if 

you don't agree with the license terms. 
Pros: 

1. MAXScript allows quick, easy customization and simple tool creation. 

2. All the little bug fixes (especially VRML exporter) make this product more stable and 
easier to use. 

3. 0penGL/Direct3D support allows users to use inexpensive graphics cards. 
Cons: 

1. "Frozen" (noncustomizable), cluttered, mouse-centric interface slows down experi- 
enced users. 

2. Incompatible .MAX file formats make sharing data near-impossible with MAX 1 users. 

3. Assorted documentation problems (inadequate tutorials, multiple online help sys- 
tems, and so on). 

Competitors (with estimated prices): Softimage 3D ($7,500); Softimage 3D Extreme 
($15,000); Lightwave ($i,995/$i,795); Alias PowerAnimator; Electric Image 
($2,495/$2,395). 



MAX's database, UI, and (to a degree) 
the file system. It can also access plug-in 
functions, which is very impressive, and 
it can even use OLE to integrate with 
external applications, which is bloody 
amazing from a user's point of view. 

I spoke with a plug-in developer 
about the power of MAXScript. He said 
that his commercial product could 
have been written in MAXScript and 
that he foresees MAXScript being very 
useful as a prototyping tool for plug-in 
developers. This is good news for starv- 
ing artists; I hope we see cheaper 
(albeit slower) MAXScript versions of 
commercial plug-ins. 

From what I can see, MAXScript is 
great, but there's always room for 
improvement. I'd like to see multitask- 
ing. I want to write scripts that run 
concurrently with MAX. I'm also con- 
cerned about security. MAXScript's 
power is quite broad, and scripts are 
easy to download and execute. Many 
users aren't experienced programmers 
and don't know how to review code for 
malicious behavior. I worry that 
MAXScript is an ripe environment for 
dangerous viruses (much like Word 
macro viruses, only worse). I think 
Kinetix should take a proactive role in 
preventing disaster for its users. 

.MAX File Woes 

There is one major issue you should 
be aware of: MAX 2 writes a new 
kind of file format that's incompatible 
with MAX 1. Kinetix has confirmed 
that this is true, and hasn't announced 
any plans to fix it. 

Who cares? More people care than 
you might think — specifically, anyone 
who uses MAX 1 and MAX 2 on the 
same project. For example, you buy 
MAX 2, but your customer/client/art 
director hasn't upgraded their MAX 1. 
How do you show them your artwork? 
You're stuck with using lame .3DS files 
to get data out of MAX 2 and back into 
MAX 1. You'll lose data because .3DS 
files don't store things such as multiple 
UVs per vertex. 

Why did Kinetix do this? Is it an evil 
plot to force all MAX 1 users to 
upgrade? Or did Kinetix innocently say, 
"Let's make the .MAX file better," with- 
out considering how MAX 2 will be 
used with MAX 1? I think Kinetix (or 
some other plug-in developer) should 
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fix this discrepancy by creating a MAX 
1 -compatible .MAX file exporter. 



New Features Replace Plug-ins 

A number of new features overlap 
existing plug-ins. The most obvi- 
ous is the morph blending feature. This 
allows the user to set multiple morph 
targets and blend between them. It offers 
features very similar to MorphMagic, 
Smirk, and Mix (there's a good review of 
these three in the December 1997 issue 
of 3D Artist magazine, though it mistak- 
enly says that MAX 2 doesn't offer this 
feature). Users report that morph blend- 
ing works fairly well, but not as smooth- 
ly as the plug-ins do. A bunch of other 
features also invade plug-in territory: 
Bones, Lens flare, and the Sun System, 
which creates correct sun positioning 
given a latitude and longitude. 

It's interesting to watch Kinetix 
attempt to balance its desire to leave 
room for plug-in developers with its 
attempts to increase MAX's feature set. 
The message behind MAX 2 is that 
Kinetix has no problem stepping into 



its developers' markets if it will make 
MAX better. That's good for users, but 
bad for developers — it reminds me of 
Microsoft's tactics. 



Gossip 

After I'd played with MAX 2 long 
enough to form an initial impres- 
sion, I asked some of my peers about it. 
First, I e-mailed a few artists; their com- 
ments are scattered through this 
review. Then I went to the local San 
Francisco 3D Studio Users' Group 
meeting. 

About half the people at SF3DSUG 
had used MAX 2, and they seemed to 
think it was worth the money, especially 
since many of MAX 2's built-in features 
saved them the cost of having to buy 
certain plug-ins (such as lens flare). Not 
everybody was totally thrilled, though. 
There was some heartfelt complaining 
about the printed documentation. "We 
want more than reprinted MAX 1 manu- 
als," was a refrain that I heard more than 
once. Another hot topic was the attempt 
to get MAX 2 working with cheap 3D 



accelerator cards (sound familiar?); 
many varied opinions were bandied 
about and some good data was collected. 
Notably absent (or perhaps incognito) 
were Kinetix employees — I would have 
expected someone from Kinetix to be 
there, but at that particular meeting, no 
one was. There was a MAX dealer who 
seemed to speak on Kinetix's 
behalf /defense, which was helpful. 



The Drum Roll... 

MAX 2 is better than MAX 1. Is it 
$800 better? That depends on 
what 800 bucks means to you. If you're 
a hungry freelancer who barely came 
up with the cash for MAX 1, then you 
can get by without MAX 2. It's better, 
but it isn't going to change your work 
enough to justify the cost. 

On the other hand, most art depart- 
ments and freelancers with healthy 
incomes should definitely upgrade: you 
could save the cost of the upgrade just 
by using cheap 3D graphics hardware (if 
you can get it working) and plug-ins (if 
you haven't already bought them). ■ 
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E emble Age OF Empires 



Matt PritcU 



a r 





had an experience in a local computer 
store recently that caused me to burst 
out laughing. I had stopped to self- 
indulgently admire the top- 10 PC 



games display when I overheard the 
following exchange between two 
young men: 




"What do you think about this one, Age 
of Empires?" wondered the first. 



His companion shot back, "Aww, the 



Borg at Microsoft just combined Warcraft 



and Civilization to cash in on these kind 



of games." 



Always eager to boost our sales, I took 
this opportunity to tell the young men 
how AoE wasn't the creative product of a 
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The Age of Empires development team. The author is second from the 
right in the row of guys who are kneeling. 



giant corporation, but of a small group 
of talented people living right in their 
own backyard. 

For us, Age of Empires was not only a 
game of epic proportions, it was an 
epic journey for a small band of people 
determined to turn an idea into a real 
game company. Along the way, we 
laughed, we cried, we consumed pizza 
and caffeine, and we learned a great 
deal about making games. 

Designing the Past Perfect 

Obviously, Age of Empires didn't 
start out looking like the final 
product. Despite some accusations, 
Dawn of Man (AoE's original title) 
wasn't created to be a Warcraft II 
clone. (In fact, Warcraft II wasn't 
released until after AoE's development 
was well underway.) Instead, the final 
design was evolved and refined over 
time, with a few significant design 
events along the way. One of the best 
things I think you can have in a game 
company is a staff that plays a lot of 
different games. This was true of our 
staff at Ensemble, and was helped in 
no small part by programmer Tim 
Deen's habit of buying and actually 
playing almost every new PC game as 
it came out. It was Tim who brought 
Warcraft II to the attention of the 
rest of the Ensemble staff. At that 
time, many of AoE's game elements, 
such as resource management, empire 
building, and technology research, 
were taking clear shape. However, we 
didn't really know what to do about 
combat. Warcraft II was a splash of 
cold water in the face, waking us up to 



how much fun real-time combat could 
be. Several times a week, the staff 
would stay late to play multiplayer 
Warcraft. These impromptu events 
continued until AoE reached the 
point in development when it became 
more fun to play than Warcraft. 

Another major shift occurred a little 
over halfway through development, 
when the designers were looking at 
AoE's localization plans. They realized 
that AoE would be sold in Asia, but 
didn't include a single culture from that 
region. We held a company-wide meet- 
ing and decided to add early Asian civi- 
lizations to the early European, African, 
and Middle-Eastern tribes that we'd 
already developed. Though the addition 
would create more work for the artists 
and designers, the enhanced appeal that 
the game would have in Asia would 
make this a profitable decision. 

All of these changes occurred 
because the game's designers weren't 
afraid of taking design input from the 
rest of the staff. Making a game that 
everyone would be proud of and would 
want to play was something that got 
more than just lip service at Ensemble. 
Perhaps the best example of this core 
value is the Wonder, the penultimate 
building that a player can build and 
use to win the game. In early 1997, 
AoE was great for slugfests, but every- 
one felt that the game play needed to 
offer something more. Numerous ideas 
were tried and rejected. Then Mark 
Terrano, our communications pro- 
grammer, hit upon the idea of building 
an " Armageddon Clock" that would 
force players to drop what they're 
doing and respond to the new chal- 
lenge. AoE is chock full of little ideas 
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and touches that were thought up by 
the artists and programmers. This par- 
ticipation tangibly increased the sense 
of ownership and pride that we all took 
in the game. 

One of things that is truly under- 
appreciated about the designer's job is 
play balancing. The designers spent 
months and months adjusting costs, 
strength, speed, and many other statis- 
tics in an effort to create a game that 
was fun to play and yet didn't offer any 
loopholes or cheats. At this point, I real- 
ized that Tim Deen was truly a gamer's 
gamer. During development, if any of 
the various iterations of AoE's design 
opened up a way for one player to take 
advantage of another player and thus 
make the game one-dimensional, Tim 
would find it. And when we didn't 
believe his assessments, he would 
promptly show us by using the loophole 
to kick our butts at the game. For the 
better part of a year, play balancing was 
a prominent task, and it paid off in giv- 
ing AoE more staying power and better 
game play than many others in the 
recent crop of real-time strategy games. 



Blazing the Multiplayer Path 

ultiplayer support was an inte- 
gral part of the early design, and 
AoE was structured in such a way that 
most of the game could not differenti- 
ate between human and computer 
players. When DirectX first came out, 
it appeared that DirectPlay would be 
the best choice for providing commu- 
nications over the widest variety of 
connection types. 

To support a high number of moving 
units, we went with a modified game 
synchronous model, where the entire 
game is simultaneously run on all 
machines. Only moves, changes, and 
commands are communicated to other 
machines. This approach has the 
advantage of minimizing the amount 
of data that has to be sent. The unan- 
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ticipated danger of using this model is 
that it can generate a condition where 
the game on one machine becomes out 
of sync with the game on other 
machines. This caused some very hard- 
to-reproduce bugs with AoE. 

Load metering, the process of deter- 
mining how much bandwidth the game 
updates required, was done before the 
computer AI was completed, and was 
based on the data flow model taken 
from human players. As a result, we ini- 
tially missed the fact that computer 
players would sometimes issue large 
numbers of commands in quick bursts. 
We did, however, address this oversight 
with the first patch. An area where 
AoE's communications worked out bet- 
ter than expected was the game's ability 
to dynamically adapt to latency. A slid- 
ing window delays the actual game time 
when a command takes effect, so that 
all players receive the command and do 
not have to pause before executing it. 

The problem of handling players 
who have dropped from a game pre- 
sented Mark Terrano with difficult 
challenges. Since drops are unpre- 
dictable, usually there is no way to 
know what happened. The problem 
could be the game logic, Winsock, the 
physical connection, or the ISP, and 
could exist on either the sender's or 
receiver's side. Getting the game to 
handle drops by anyone at anytime 
required a great deal of work. 

One of the lessons learned from the 
multiplayer experience was to make 




full use of communica- 
tions testing tools, such 
as automated logs and 
checksums. Also, we 
discovered that creating 
a simple communica- 
tions data flow simulator 
program can provide great benefits and 
isolate the communications code from 
the rest of the game. 

DirectPlay also turned out to be 
problematical. Difficult-to-reproduce 
bugs, quirky behavior, and poor docu- 
mentation made the going more diffi- 
cult. Guaranteed packet delivery for 
IPX was one of the more notable exam- 
ples. At the CGDC, Microsoft promised 
to deliver this feature with DirectX 5 
and even included in the beta. 
However, when DirectX was actually 
released, this feature was nowhere to 
be found. The cost of that one missing 
item was the extra time we had to 
spend writing our own guaranteed 
delivery system and a bad packet gen- 
erator program with which to test it. 



Painting the Scene 

A 



ge of Empires contains 20MB of 
in-game sprite graphics. Even 
though all of the displays are 2D, we 
decided early on that all of the graph- 
ics in the game would be taken from 
3D models. We used 3D Studio and 3D 
Studio MAX for art production. 
Because 3D rendering is so time-con- 
suming, each artist was issued two 
machines each, both usually 200MHz 
Pentium Pros with 128MB of RAM, 
which at the time was better equip- 
ment than the programmers were 
using. The objects in the game were 
created as 3D models that had any- 
where from a couple thousand to 
100,000 polygons. The models were 
then textured, animated, and rendered 
out to a .FLC (Autodesk Animator) file 
with a fixed 256-color palette. 

So far, the process I've described is 
identical to that of many other games. 
At this point, however, the artists added 
another time-consuming step. The .FLC 
files were handed off to a 2D specialist, 
who took the animation apart frame by 
frame and "cleaned up" each image 
with Photoshop. The clean-up process 
involved sharpening detail and 
smoothing the edges of the irregular 
shapes. Since most of the sprites in AoE 



had screen dimensions of only 20 to 
100 pixels in each direction, the visual 
quality improvement that we realized 
was significant. When AoE was shown 
at the 1997 E3, the artists received 
numerous compliments on their work 
from their peers at other companies. 

The choice to go with 3D models for 
the in-game objects provided benefits 
for other art needs, as they were readily 
available for use in the static back- 
ground scenes that appear on the 
menu, status screens, and the various 
cinematics. The cinematics, including 
the three-minute opener, were a full- 
time project unto themselves. 

The 256-color palette (actually 236) 
used in AoE was something of a prob- 
lem. The palette was chosen and set in 
stone at the very beginning of the pro- 
ject, before most of the models and 
textures had been created. As a result, it 
turned out that some portions of the 
color spectrum, such as browns for 
wood textures, had too few available 
colors to get the best visual quality. 
The palette wasn't revised during the 
development process because that 
would have required rerendering and 
touching up every image in the game 
— far too expensive time-wise. On the 
other hand, the palette did have a wide 
and balanced range of colors, which 
contributed to the overall bright and 
cheerful look of the game's graphics. If 
we do another 8-bit color game, we'll 
generate the palette at a point further 
along in the development process. 



Going for Speed 



Performance is an issue for all but 
the simplest of games, and it cer- 
tainly was for AoE. When I joined 
Ensemble, the game was still in an early 
form and slow. The two biggest prob- 
lems were the graphics engine (which 
was just plain slow) and various update 
procedures, which produced occasional 
pauses of up to a second in game play. 
If we were going to sell to anything but 
the most cutting-edge systems, some 
serious optimization was in order. The 
story gets personal here, as I did a great 
deal of the work on this part of AoE. 

I started by trying to get a handle on 
what the over 100,000 lines of C++ 
code did (the source would rise to over 
220,000 lines before it was finished). 
After spending a few weeks studying 
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All of the 2D sprites in AoE began life 
as 3D models. 



Early Asian civilizations had to be 
added when Microsoft announced 
plans to distribute AoE in Asia. 



what we had, I proposed a major over- 
haul of the graphics engine structure, 
including writing a major portion in 
assembly. AoE's original design team 
asked if the frame rate of a benchmark 
scenario could be raised from its cur- 
rent 7 - 12 fps to 20 fps. I told them 
yes. Inside I was sweating bullets, hop- 
ing that I could deliver that much 
improvement. 

I couldn't just go ahead and rip out 
the old graphics engine, as it would 
hold up everyone else, so I spent the 
next five months working mostly on the 
new engine. Along the way, I managed 
some incremental improvements that 
upped the frame rate to 10 - 14 fps, but 
the big breakthrough came during an 
all-nighter, when the last piece of the 
new design was put into place. Much to 
my surprise, the benchmark scenario 
was now running at 55 fps. It was excit- 
ing to come back into the offices the 
next day and see the formerly sluggish 
animation running silky smooth. But 
my work was not all on the graphics 
engine. I also spent a great deal of time 
identifying and optimizing myriad 
processes in the game. Since the game 
was real-time, many improvements 
involved spreading out a process over 
several turns rather than of stopping the 
game until it completed. In the end, the 
optimizations paid off handsomely and 
allowed us to raise the default resolution 
from 640x480 to 800x600. 

A practical lesson that I learned from 
this experience was how much addi- 
tional overhead and slowdown a game 
can acquire as it approaches comple- 
tion. Often, early in a game project the 
engine will show great performance — 
but the game's not finished. When you 
replace the simple test levels with the 
complex final levels, add all the AI, UI, 
and bells and whistles, you can find a 
world of difference in actual perfor- 
mance. This was true for AoE as well. 
As we approached completion and all 
of the loose ends were tied off, many of 
the performance gains were traded in 
for new features. 



Things That Worked Out (S)well 

IThe game was broken into separate 
• ENGINE AND GAME COMPONENTS. About 

halfway through development, there 
was concern that the code base had 
expanded far enough beyond the ini- 



tial design in some areas that every 
new change and addition would look 
like an ugly hack. Lead programmer 
Angelo Laudon and Tim Deen took two 
weeks and separated the code base into 
two separate sections, the general 
engine (Genie), and the game itself 
(Tribe). The conversion was very suc- 
cessful and allowed the AoE program- 
mers to retain a nicely object-oriented 
design. The benefit here was that it 
made the code much easier to modify 
and extend, saving the programmers a 
great amount of development time. 

2 We made the game database driven. 
• Thanks to the object-oriented 
design, almost nothing about any 
object in AoE is hard-coded into the 
program. Instead, huge tables of infor- 
mation describe every characteristic of 
every object that appears in the game. 
The designers used a system of over 
forty Paradox tables to control and 
shape the game. As a result, they were 
able to constantly update and tweak the 
game, and then test their changes with- 
out having to involve a programmer. 

3 We stayed in close contact and work- 
• ing together with the publisher. i 
can't say enough good things about 
how the close contact with our pub- 
lisher, Microsoft, helped the develop- 
ment of AoE. By keeping them "in the 
loop" on our progress, they worked 
with us instead of against us as things 
happened. The best example of how 
this relationship aided development is 
the way we handled schedule slippage. 
Each time something took longer than 
expected or new problems cropped up, 
we effectively communicated the delay 
to Microsoft. With a clear understand- 
ing of what was happening and why, 
they reaffirmed their commitment to 
assist us in producing a quality game, 
whatever amount of time that would 
take. So instead of being panic-stricken 
and whacked out, we remained profes- 
sional and focused on 
our goals. 

4 We played our own 
• game. While this 
may sound simple, it's 
very important. 
Throughout the devel- 
opment process, every 
person in the company 
not only play tested, 
but played AoE with 
the purpose of having 
fun. As a result, we were 



very in tune with why the game was 
fun, and what people were likely to get 
out of it. We had 20 guys who were 
determined not to let the game play be 
compromised or watered down. 

5 Performance was good. Perfor- 
• mance truly means a lot if you 
want your game to have broad appeal. 
Age of Empires can adequately run an 
eight-player game in 16MB of RAM on 
a P120 system. Contrast that with 
Total Annihilation, which requires 
32MB and at least a 200MHz CPU for 
an eight-player game. Achieving this 
level of performance required a group 
effort. The programmers expended 
extra energy on keeping memory con- 
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sumption in check and identifying bot- 
tlenecks, while the artists culled extra 
animation frames and reorganized the 
graphics to maximize free memory. 

6 The company respected its employees. 
• I have to say something about the 
way Ensemble Studios treated its 
employees and their families. It is well 
known that software development, 
especially game development, involves 
great sacrifices of time and can be hell 
on personal relationships. Ensemble's 
thoughtful management respected that 
by going out of their way to include 
families at numerous company dinners 
and other events, and to make them 
feel welcome to come by the offices at 
any time. Additionally, after crunching 
hard to meet a milestone, they would 
insist that employees take a couple of 
days off to catch up with their families. 
People were allowed flexible schedules 
if they needed them, and flowers or 
other tokens of appreciation were sent 
to the families periodically. The result 
of this deliberate action by company 
management should be obvious; com- 
pany morale and loyalty was higher 
than I have ever seen in fourteen years 
of software development. My wife 
loves my job as much as I do. 
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/Localization really worked. 
• From the beginning, we 
knew that Microsoft wanted to 
release AoE in six different lan- 
guages, including Japanese. 
About halfway through develop- 
ment, we updated our code base 
to provide full localization sup- 
port. This required stripping out 
and replacing all text references 
in the source code and maintain- 
ing all game text in an external 
resource file. It also placed severe 
restrictions on how we could draw 
and display the text. We had to use the 
Windows GDI exclusively, something 
most games shun like the plague. It also 
meant that interface items such as but- 
tons had to be sized to hold the largest 
possible translated form of their cap- 
tions, limiting the clever things one 
could do with the design of the user 
interface. But we buckled down and did 
it, following the guidelines exactly. And 
to our pleasant surprise, the conversion 
was swift and painless. We felt even bet- 
ter when the translators at Microsoft 
told us that localizing AoE was the 
smoothest and most pain-free project 
they had ever done. The benefit to us 
was enormous in that we had a single 
executable program file that was the 
same for all translated versions of the 
game, thus avoiding the huge headache 
that comes with tracking bugs and 
releasing updates for multiple versions. 
We worked as a team that respected 

ALL ITS MEMBERS. A project of AoE's 

size required that we all work together 
in close quarters for extended periods 
of time. One of our expressed criteria 
in hiring new people is that we must be 
able to respect each other. This respect, 
complemented by the company's 
actions towards its employees, fostered 
an excellent sense of 
family and team spirit 
among everyone. We 
avoided having differ- 
ent groups develop a 
sense of isolation from 
the project, and as a 
result, attitudes and 
spirits remained high 
even during the worst 
crunch time. Had tem- 
pers flared and cliques 
developed, I honestly 
don't believe that AoE 
could have made it out 
the door in 1997. 
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Things That Went Wrong Or We Could 
Have Done Better 

IWe held the beta test too late in the 
• development cycle. A public beta 
test of AoE was held in August 1997, 
but we didn't come near to exploiting 
the full potential of it. We were too 
close to the end of the project to make 
any game play changes, despite the 
wealth of useful feedback we received. 
Manuals were already set to be printed, 
and most of the design had been set in 
stone. All we could really do was fix 
any bugs that were found. For any 
future projects, we vowed to hold the 
beta testing earlier. 

2 There was inadequate communi- 
• CATION WITH THE QA PEOPLE AT 

Microsoft. For most of the project, 
bug reporting was handled through a 
database and developers didn't 
directly communicate with the 
testers. As a result many bugs wound 
up taking much longer to resolve, 
and new features went untested. An 
intermediate database was simply not 
enough to let testers and developers 
know what the other was really 
thinking. In future projects, we 
would like to assign a specific tester 
to each programmer and have them 
communicate by phone every couple 
of days. Near the end of develop- 
ment, this did happen for a couple 
people — for them productivity with 
testing and bug resolution was drasti- 
cally improved. 

3 We sometimes failed to coordinate 
• development through the leads. yet 
another area where personnel commu- 
nication could have improved the 
development was among our own 
teams. Each team — Programming, 
Art, Game Design, and Sound — has a 
lead person who is responsible for 
keeping track of what each member of 
his or her team is doing. The lead is 
the go-to person when someone out- 
side has new requests for the team. As 
the development of AoE progressed 
and the pressures rose, adherence to 
this system broke down as people went 
direct to get their needs filled quickly. 
We paid a price for it. People didn't 
know about programming changes or 
new art that was added to the game, 
and the level of confusion rose, creat- 
ing a time drain and distraction. We 
all had to stop at times just to figure 
out what was going on. 
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4 We failed to adequately test multi- 
• PLAYER GAMES WITH MODEM CONNEC- 
TIONS. One problem with our develop- 
ment environment is that it isn't 
comparable to the typical end user sys- 
tem. During the course of develop- 
ment, the multiplayer portions of AoE 
were tested extensively. When we 
played a game in the office, our fast 
machines, stuffed full of RAM, commu- 
nicated with each other on our high- 
speed LAN. When we tested Internet 
play, our communications were han- 
dled through the company's Tl line. 
One thing that we failed to realize in 
our testing was the fact that most play- 
ers would be using dial-up modem con- 
nections to commercial Internet ser- 
vice providers. And it wasn't just us; 
the same situation applied to the test- 
ing labs at Microsoft. As a result, 
modem connection games were under- 
tested. Bugs that were harmless when 
ping times were low resulted in 
dropped games for users on slower 
Internet connections. And our high- 
speed network masked the fact that 
under certain not-so-uncommon cir- 
cumstances, AoE could require 15K of 
network bandwidth per second — six 
times what even a 56K modem can 
provide on the uplink side. As a result, 
we were taken a bit by surprise when 
reports of multiplayer game problems 
rolled in. Though our first patch fixed 
this problem, the situation was unac- 
ceptable. Now, each developer has a 
modem and several different ISPs are 
used, as modem testing is a big part of 
our testing process. 

5 Portions of development relied on 
• PRODUCTS THAT WERE NOT DELIVERED ON 

time. There was a second reason that 
modem games were under-tested; prob- 
lems with the delivery and quality of 
DirectPlay from Microsoft. Features that 
were promised, and even included in 
beta releases, weren't present when the 
delayed final release was delivered. 
Direct X 5a wasn't available to us until 
a month before the game shipped. In 
the meantime, our communications 
programmer was burning the midnight 
oil writing the functionality that was 
expected but not delivered. Waiting on 
promised drivers and SDKs is one of the 
harder things that developers have to 
deal with, even those with Microsoft as 
a publisher have no control over them. 

6 We did not plan for a patch. The 
• version 1.0a patch, even though 




it was a success, was problem- 
atic in that as a company we 
had not planned for it. The 
general argument is that if you 
know you are going to need to 
release a patch, then you 
shouldn't be shipping the 
game in the first place. While 
one can take that stand, it's 
also a fact that no game devel- 
oper's testing can match that 
of the first 50,000 people who 
buy and play the game. Your 
customers will do and try 
things that you never dreamed of, 
while running on hardware and dri- 
vers that you never heard of. Looking 
around, nearly every significant game 
released this year has had a patch or 
update released for it. Rather than 
deny this reality, we would like to 
allocate resources and expectations in 
the future so that we can release any 
necessary updates days or weeks after 
our games ship, rather than months. 

7 We didn't manage "surprise" events 
• as well as we could have. During 
the development period, we experi- 
enced several sudden events that 
caused us, as a company, to stop what 
we were doing. These events included 
the creation of a demo version of the 
game and materials for press coverage 
of AoE. While most of the events were 
beneficial to the company, we weren't 
very good at handling them, and they 
threw off our schedules. These disrup- 
tions mostly came late in development, 
when their impact was felt the most. 
One of our goals for future games is to 
minimize the impact of unplanned 
events by giving advance notice when 
possible and restricting them by mini- 
mizing the number of people that have 
to respond to them. 

8 We didn't take enough advantage of 
• automated testing. In the final 
weeks of development, we set up the 
game to automatically play up to eight 
computers against each other. 
Additionally, a second computer con- 
taining the development platform and 
debugger could monitor each comput- 
er that took part. These games, while 
randomly generated, were logged so 
that if anything happened, we could 
reproduce the exact game over and 
over until we isolated the problem. The 
games themselves were allowed to run 
at an accelerated speed and were left 
running overnight. This was a great 
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success and helped us in isolating very 
hard to reproduce problems. Our fail- 
ure was in not doing this earlier in 
development; it could have saved us a 
great deal of time and effort. All of our 
future production plans now include 
automated testing from Day One. 



Patching It All Up 

Once AoE was shipped off to pro- 
duction, we threw ourselves a big 
party to let off some stress. It turns out 
we were a bit premature in our revelry. 
Shortly after AoE arrived on store 
shelves we began receiving feedback 
on problems with the pathfinding, 
unit AI behaviors, population limits, 
and multiplayer play. Additionally, 
some bugs were found that a player 
could exploit to gain an unfair advan- 
tage in the game. Management was 
stirred to action at both Ensemble and 
Microsoft, and the decision to do a 
patch for AoE was made. 

Although time was taken away from 
other projects, and it took longer than 
desired, the patch was a success; it vast- 
ly improved the quality of multiplayer 
games, fixed the bugs, and addressed 
the game play concerns that had been 
raised. And that brings the develop- 
ment of AoE to where it is today, 
which I hope is somewhere on your 
hard drive... ■ 
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Don't Lie 

on Your Resume 



b u J o It n PodlaAeL 





esumes are a funny thing. They're a 
pain-in-the-ass to write, but you can't 
get a job (that doesn't require you to 
wear a name tag) without one. It's a 



time-consuming, frustrating, necessary 
evil, especially in the shaky and 
volatile world of the game develop- 
ment industry. At Blue Byte Software, 
we get around a dozen resumes every 
week from interested job seekers. It's 
pretty easy to see who's got their act 
together within the first few minutes, 
based not just on presentation, but on 
background, experience, and educa- 
tion. The company president passed 
along a resume to me a few weeks ago 
that shocked me unlike anything I've 
read before. 

It started with the sheer size of it — 
six pages. Yes, you read that right, six 
pages. Unless you're say, Winston 
Churchill, I don't see how you could 
logically come up with enough accom- 
plishments to fill four pages, let alone 
six. So I read on, more for amusement 
than from any desire to "get this indus- 
trious go-getter in for an interview." 

After three pages of objective, sum- 
mary, and experience, Mr. Joe Blow 
(the name has been changed to protect 
the clueless) got to 'Titles as of July 
1997." Three pages of games followed, 
listing title, platform, position, and 
genre (an amazing 154 total — many 
listings were for the same game on var- 
ious platforms and/or never-published 
titles). When I got to the last page, 
however, my jaw nearly hit the floor. 
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One of the titles for which he had 
listed himself as producer was a game 
that J had designed and produced. 
My first reaction was, "Who the f#*& is ^ 
this nimrod?" because I've never met, 
spoken, e-mailed, or worked with him 
As I read on, I discovered more 
titles where he had listed 
himself as producer for a 
defunct gaming division of a 
big corporation that I used to 
work for (and can't name for 
fear of hungry "separation let- 
ter" attorneys). It was basically 
the entire catalogue of the divi 
sion's last year and a half — 25 
titles in all. 

So I told some other game indus- 
try people about it, people whose 
work he'd taken credit for. Their 
responses range from "mad" to "let- 
ter-bomb-ready" pissed. After doing 
some digging on Joe Blow, I found 
out that he spent a few weeks as a 
worthless third-party producer 
on a nonpublished game at a 
division of a company that 
had short-lived plans of 
merging with my former 
division. Although the 
connections are get- 
ting confusing, 
the point is that 
Continued on page 63, 
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Continued from page 64. 
these are games that he didn't produce 
for a company that he didn't even 
work for. Amazing. 

Anyone who's been in this industry 
for even a short period of time knows 
that it's more incestuous than an 
Alabama family reunion. Between the 
layoffs, mergers, and millions lost, plus 
the relatively small work force, people 
get around. They talk, have friends 
that left to work for other companies, 
share drinks, attend seminars and 
shows, and so on. It's ridiculous to 
think, "No one will find out." 

Some may ask, "Why make such a big 
deal about it? The division isn't around 
anymore, the games weren't that popu- 
lar, and he needed to beef up the 
resume. "My response is, "He lied!" 
Besides the obvious ethical question, 
stealing credit for games that you didn't 
work on cheapens and belittles the late 
hours and hard work put in by the peo- 
ple who did. It's disgusting to think 
back on all the headaches, frustrations, 



and late nights put in on a game to just 
have someone take the credit from you. 
Don't get me wrong. I'm not complain- 
ing about the hard work. It's the nature 
of the beast in game development. 
Besides, I know of a million more diffi- 
cult ways to make a living than making 
games. The point is that when you put 
this much effort into a project (of any 
kind, really), it magnifies the attach- 
ment. When the level of effort, intensi- 
ty, and time required for game develop- 
ment is expanded, you take your titles 
personally. 

One other point stands apart from 
the ethical question and the attach- 
ment factor: survival. Having been out 
in the job market a little over eight 
months ago, I wondered, "What if this 
yahoo got a job over me because of the 
titles he lied about?" Most likely, any 
company dumb enough to hire him is 
someplace you don't want to work for 
anyway, but the possibility is cause for 
concern. Besides my own personal rea- 
sons, I have honest, hard-working 



friends out in the job market compet- 
ing with this schmuck. It makes me 
even angrier knowing that good people 
may lose out on an opportunity 
because some guy thought nobody 
would know or care if he lifted a cou- 
ple dozen game titles for the resume. 

But our friend Joe Blow isn't the 
only one guilty (just the most stupid 
and blatant). He's more of a poster boy 
for this dirty little secret that nobody 
talks about. And it's not even limited 
to resumes. I've read articles and web 
pages published by people with whom 
I used to work that twist, exaggerate, 
and simply lie about past titles for 
which they're claiming undue credit. 

My advice? Keep your resume well 
under six pages (unless you helped save 
Western civilization) and don't lie about 
the games that you didn't work on. The 
industry is small and well-connected, 
and it may come back to haunt you 
down the road. Who knows? Someone 
may even write a magazine article about 
how stupid you are someday. ■ 
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3D Labs 


22 


Intel 


C2/1 


3Name3D 


55 


MultiGen 


6/7 


Animatek International 


2 


Numerical Design 


19 


Caligari Corp. 


62 


Oak Technology 


14 


Conitec Datensysteme Gmbh. 


21 


Quantum 3D Inc. 


8 


Diamondware 


55 


RAD Game Tools Inc. 


C4 


Digital Equipment Corp. 


10/11 


Raindrop Geomagic 


48 


Immersion Corp. 


29 


Stormfront Studios 


62 


InstallShield Software Corp. 


C3 


Tiburon Entertainment 


62 
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